GLIBC_PRIVATE what is it?
Pawel
I got following message when trying to install dante rpm package on my
fc6:
error: Failed dependencies: ld-linux.so.2(GLIBC_PRIVATE) is needed by
dante-1.1.19-1.i386
My question is what GLIBC_PRIVATE really is? This is not first time I
see this message, so I would like to learn a bit about it.
Unfortunatelly googling leads me to huge amount of problems with this
symbol but not the explanation of what it is.
Could You give me some links or short explanation on this.
Regards, Pawel.
Nix
> I got following message when trying to install dante rpm package on my
> fc6:
>
> error: Failed dependencies: ld-linux.so.2(GLIBC_PRIVATE) is needed by
> dante-1.1.19-1.i386
>
>
> My question is what GLIBC_PRIVATE really is? This is not first time I
> see this message, so I would like to learn a bit about it.
GLIBC_PRIVATE is the version given to symbols exported by the GNU C
library only for the purpose of communicating with other parts of the
library.
I don't know how familiar you are with shared library versioning, but
basically there are two overlapping ways to version shared libraries.
You can set the library SONAME field to a name which includes a version
number: users must set their DT_NEEDED field to the same name to use the
library. Generally changes of major version are recorded this way: so
foo.so.3.2 and foo.so.3.3 would probably both have an SONAME of
foo.so.3, and API changes would be avoided until foo.so.4. (The
DT_NEEDED fields can be seen on the left- hand side of the arrows when
you run ldd on some binary or shared library. The SONAME field can be
seen by running readelf -a on a binary or shared library.)
This is better than what Windows has got, for instance, but it's still
not really good enough. Things that everyone links against like C
libraries can basically never rev their soname because it would require
everyone to relink (remember when libc5 faded out? It was really
annoying). So instead they attach versions to every symbol.
Symbol versions are documented to some degree in the ld info pages: but
an ELF symbol version is basically a way to note what set of symbols was
present in the library some program linked against (or, rather, what
`versions' are needed: versions are arbitrary tags), and not show it
symbols with later versions. A GNU extension to this allows renaming of
symbols as well, so that you can have several symbols with identical
names, with the right version being automatically picked up at dynamic
link time. e.g.
_IO_file_fopen@GLIBC_2.0
_IO_file_fopen@@GLIBC_2.1
Here, programs linked against a library which had the version set
GLIBC_2.0 but not GLIBC_2.1 defined would see the first symbol as
_IO_file_fopen; the others would see the second symbol. (That @@
means `default').
So when you try to link a program that asks for _IO_file_fopen against
that library, it'll look for the default one, look up its version set
(GLIBC_2.1 in this case), link against that symbol, and add GLIBC_2.1 to
the version needs section of the program you're linking. After that,
even if you use a library that has a later version of the symbol, your
program will still pick up the older one.
Those versions are entirely arbitrary; glibc has chosen to have versions
named things like GLIBC_2.0, GLIBC_2.1, GLIBC_2.4 and so on. But glibc
is composed of several shared libraries with tight interdependencies:
/lib/libc-2.5.so will pull symbols from /lib/ld-linux.so.2,
/lib/libdl-2.5.so does little *but* call things in libc-2.5.so and
ld-linux.so.2, and libpthread has horrifically elaborate dependencies
on all these things.
Now the interfaces that glibc's pieces use to talk to each other used to
be public but undocumented: but then some idiots working for a company
named after the brightest star in the daytime sky decided that it would
be useful for a programming environment named after a kind of coffee to
call some of these functions. I mean, how could they have been expected
to think that functions with names like __libc_init() were internal?
So the glibc maintainers wrapped these internal-only symbols in a new
version set, GLIBC_PRIVATE. There are no compatibility guarantees at all
about such symbols: they can go away in minor releases, appear without
warning, or dance the fandango. If you use anything marked GLIBC_PRIVATE
and you're not hacking glibc itself then you deserve to lose when glibc
is upgraded: but alas the linker doesn't seem to warn when you use such
symbols. (It used to: maybe this is a bug. I'll look into it.)
> Unfortunatelly googling leads me to huge amount of problems with this
> symbol but not the explanation of what it is.
It's a version, not a symbol.
Extract the binary from that RPM and run it like this:
LD_DEBUG=bindings the_program_name 2>&1 | grep GLIBC_PRIVATE | grep the_program_name
and see what symbols it's complaining about. (The last grep is just to
avoid bugging you with PRIVATE bindings of symbols inside glibc to users
of those symbols inside glibc.)
--
`In the future, company names will be a 32-character hex string.'
--- Bruce Schneier on the shortage of company names
Pawel
> Path: news.task.gda.pl!newsfeed00.sul.t-online.de!t-online.de!inka.de!rz.uni-karlsruhe.de!news.belwue.de!news.n-ix.net!news2.arglkargh.de!nuzba.szn.dk!pnx.dk!news.albasani.net!zen.net.uk!dedekind.zen.co.uk!peer.news.zetnet.net!master.news.zetnet.net!not-for-mail
> From: Nix <nix-ra...@esperi.org.uk>
> Newsgroups: uk.comp.os.linux
> Subject: Re: GLIBC_PRIVATE what is it?
> Date: Wed, 16 May 2007 00:47:54 +0100
> Organization: the Core
> Message-ID: <87abw56...@hades.wkstn.nix>
> References: <m2y7jqc...@tenbit.pl>
> Reply-To: Nix <$}xinix{$@esperi.org.uk>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Emacs: more than just a Lisp interpreter, a text editor as well!
> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b27 (linux)
> Cancel-Lock: sha1:CrS6+yDd9nv0co7o+qwU78axwfM=
> Lines: 97
> NNTP-Posting-Host: 41-052.adsl.zetnet.co.uk
> X-Trace: 1179273617 master.news.zetnet.net 760 194.247.41.52:44500
> Xref: news.task.gda.pl uk.comp.os.linux:14477
Nix,
thank You for Your clear explanation so far (I am in the middle).
Best regards,
Pawel.