LWN.net Logo

A turning point for GNU libc

A turning point for GNU libc

Posted Mar 29, 2012 6:31 UTC (Thu) by michaeljt (subscriber, #39183)
Parent article: A turning point for GNU libc

I already asked in the comments to the previous article, but I think this article has made it obsolete: does anyone (Joe? Nix?) have a feeling for whether there are chances that glibc will become more friendly to static linking in the mid-term future?


(Log in to post comments)

A turning point for GNU libc

Posted Mar 30, 2012 19:10 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries, doesn't 'more friendly' imply relicencing?

Would it not be more useful for the libc headers to support a macro specifying the intended minimum required run-time version? (I seem to recall that the Win32 SDK supports something like this.) Various definitions would then be disabled or modified to match the old version, and symbol version selection would be modified too. Of course ithis would further complicate the nest of #ifdefs in the headers.

A turning point for GNU libc

Posted Mar 30, 2012 21:30 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

BenHutchings wrote:
> Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries, doesn't 'more friendly' imply relicencing?

If that is what you (generic you!) want to do the LGPL lets you link statically with proprietary applications as long as you provide object files and what-not so that you can relink the application against a rebuilt version of the LGPLed code.

A turning point for GNU libc

Posted Mar 31, 2012 12:32 UTC (Sat) by kleptog (subscriber, #1183) [Link]

GLIBC has extraordinary backward compatibility to ensure that each program runs with the versions of the symbols it was compiled against (see objdump -T on libc). If you really want to you can also choose to link against a specific version of a symbol.

http://www.trevorpounds.com/blog/?p=103
http://sourceware.org/binutils/docs-2.19/ld/VERSION.html#...

If other libraries paid as much attention to library backward compatibility the world you be a lots nicer place (you could copy binaries around between distributions and they would work).

A turning point for GNU libc

Posted Apr 1, 2012 1:54 UTC (Sun) by BenHutchings (subscriber, #37955) [Link]

If you want a program to run on older versions of glibc, you need to use the old interface definitions and the old symbol versions. Just overriding the symbol versions will generally result in your program corrupting data or crashing.

A turning point for GNU libc

Posted Apr 5, 2012 8:34 UTC (Thu) by nix (subscriber, #2304) [Link]

You'll also need the versions of libc_nonshared.a and libpthread_nonshared.a that belong to the version of glibc you're trying to use those versioned symbols from (this is one reason why arbitrary .o files are not safe to keep across glibc upgrades). All told it is sufficiently hard to make this work that it's not really worth bothering.

A turning point for GNU libc

Posted Apr 5, 2012 15:06 UTC (Thu) by khim (subscriber, #9252) [Link]

Actually this is what LSB is doing and it works fine AFAICS.

A turning point for GNU libc

Posted Apr 8, 2012 11:21 UTC (Sun) by nix (subscriber, #2304) [Link]

Yeah. I was talking about doing it by hand, yourself. :)

A turning point for GNU libc

Posted Apr 2, 2012 13:20 UTC (Mon) by jwakely (subscriber, #60262) [Link]

> Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries

Not every company distributes software. I can't remember the last time I wrote anything in my day job which wasn't for purely in-house use. The arguments in the "static linking considered harmful" piece simply don't apply in some cases.

A turning point for GNU libc

Posted Apr 2, 2012 13:28 UTC (Mon) by michaeljt (subscriber, #39183) [Link]

> Not every company distributes software. I can't remember the last time I wrote anything in my day job which wasn't for purely in-house use. The arguments in the "static linking considered harmful" piece simply don't apply in some cases.

I suppose that assuming that the new team is less unfriendly to static linking it will also be a question of whether there are enough people actively interested in it to get the necessary changes in.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds