[NTLUG:Discuss] apt-get, rpm and library versioning

[Kevin Brannen]

Burton Strauss wrote:

>Yes, but the reality of the gnu tools makes statics very difficult.
>  
>

If you can explain that, I'd love to know more.  I know of no reason why 
it should be difficult, at least technically.  Now they may be made bad 
architecture decisions in the way they put their libs together so it's 
not possible to create a sequential order for the libs to be listed 
(i.e. they have circular dependencies), but static linking in and of 
itself is quite easy, especially on Linux.

>Say you have a .a version but also the .so (perhaps even of another
>version).  Unless you force the .a into the linkage, the linker will favor
>the .so - making a dynamic library when you are SURE it's static.  One that
>won't work if the versioning is too different (say libpng 1.2.x vs 1.0.x).
>  
>

Add "-static" early in the link line and it will favor the .a libs over 
the .so libs.  Library versions are a different problem, but the person 
creating the statically linked app for others will have all the right 
versions, that's why he's doing it statically, so others won't have to 
fight that problem. :-)

>The only way around this is to finagle the linkage commands or create a
>clone library with a different name.  The problem with the clone library is
>that say there's a security problem with that library - the renamed static
>version means you have something that people scanning for insecure versions
>won't find.
>  
>

The security issue is the real killer, in that it would require a new 
binary to be created.  That being said, dynamic linking should be the 
norm, and static linking only for when you have to, so this problem 
should have minimal impact.

I guess the point I really want to make (probably not to you but the GTK 
folks really need to understand this), is that static linking has a 
place, sometimes it is the right tool for the job.  Heck, if the GTK 
boys and girls can't figure it out, I've got a library symbol analysis 
tool in my toolbox that will show them what lib needs what symbol, and 
what lib has what symbol, all in a nice pretty graph with detail data.   
This is *not* rocket science. :-)

>etc.
>
>"when you need static linking, you probably need it badly"
>
>In BOTH senses of the word, 'badly' (http://www.answers.com/badly)
>  
>

:-)

Kevin

>-----Burton
>
>-----Original Message-----
>
><snip />
>
>There is need for both.  I would say dynamic linking should be the norm for
>the reason you cite, plus the fewer files reason is nice too.
>
>But there are times when static linking is very desireable, such as when you
>(whoever but a commercial program is the most obvious) need to create a
>program that will "just work" as long as basic OS requirements are met
>(kernel, disk space, RAM, etc.).  Not worrying about what libraries are
>installed is a big relief.
>
>Static linking is also good for those programs that are very hard to make
>work/compile.  An example of this is Gaim, at least it has been hard for me
>to compile from source (and I consider myself reasonably good at building
>software, so I have great sympathy for those who don't know much about
>compiling software because they have no hope of making a working Gaim).  But
>creating a statically linked Gaim is not possible because the Gnome people
>(GTK specifically) have not created nor do they support nor will they
>support creating static GTK libs.  So if you can't get the right combination
>of software on your machine to compile Gaim, you're screwed.  Copying just
>the binary from a friend is not an option because there is no statically
>linked version of the binary.
>
>So the exceptions may be few, but when you need static linking, you probably
>need it badly.
>
>Kevin
>
>_______________________________________________
>https://ntlug.org/mailman/listinfo/discuss
>
>
>_______________________________________________
>https://ntlug.org/mailman/listinfo/discuss
>
>  
>