Help!

GLIBC_PRIVATE what is it?

 
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> UK RSS
Next:  Southern Electric e-billing site "enhanced&q..  
Author Message
Pawel
External


Since: May 15, 2007
Posts: 8



PostPosted: Tue May 15, 2007 11:02 pm    Post subject: GLIBC_PRIVATE what is it?
Archived from groups: uk>comp>os>linux (more info?)

Hallo group members.

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.
Back to top
Nix
External


Since: Jul 29, 2004
Posts: 746



PostPosted: Wed May 16, 2007 4:47 am    Post subject: Re: GLIBC_PRIVATE what is it? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On 15 May 2007, Pawel uttered the following:
> 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
Back to top
Pawel
External


Since: May 15, 2007
Posts: 8



PostPosted: Thu May 17, 2007 2:17 pm    Post subject: Re: GLIBC_PRIVATE what is it? [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Nix writes:

> 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
> 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:
> References:
> Reply-To: Nix
> 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
>
>
>
> On 15 May 2007, Pawel uttered the following:
>> 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

Nix,
thank You for Your clear explanation so far (I am in the middle).

Best regards,
Pawel.
Back to top
Display posts from previous:   
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> UK All times are: Eastern Time (US & Canada)
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum