This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: -static and others



[bringing back to life an old thread]

On Sun, 20 Dec 1998, H.J. Lu wrote:
> 
> I think we may be able to find a partial work around for -static with
> glibc 2.0 and 2.1.
> 
> 1. We make a libcompat-2.0.a which has the old libio symbols with
> version, like fopen@GLIBC_2.0.
> 2. I have a patch for objcopy which is supposed to be able to rename
> the symbols in the .o files. We run objcopy on the static library
> compiled against glibc 2.0. For those symbols whose ABIs changed in
> 2.1, we append @GLIBC_2.0 at the end.
> 3. We add -lcompat-2.0 when we use -static.

Okay, to summarize what is going on:

We need to have the possiblity of continuing to use the static
libraries compiled against glibc 2.0 on a glibc 2.1 system. The problems
occur because of the changes in the ABI of the several libio functions
(and possibly other functions too)

Question 1: Is there a list anywere that documents all these functions
whose ABI was changed between the two glibc versions?

As HJ proposed, we can create a compatibility library that will contain
the old symbols and which can be linked in together with the affected
static libraries. Everybody seems to favor the name of libcompat-2.0.x.a
for this library.

HJ is suggesting renaming the symbols in the static library some people
have expressed their doubts as to why that would be needed.

Let's say that we have a libfoo.a provided by some ISV (and there is no
libfoo.so around), and in libfoo.a we have a reference to fopen. Linking
-lfoo in a program will most likely be a fatal move, But if the
libcompat-2.0.x.a provides a symbol of fopen on its own, then things
should be fine if instead of -lfoo we link with "-lfoo -lcompat-2.0.x".
This is the intended goal. Now onto specifics:

1. We link a dynamic binary, but we have only the static version of the
libfoo.a, with its references to the old fopen. Probably our best bet is
to make sure that the linker will resolve libfoo.a's fopen references to
fopen@GLIBC_2.0 -lcompat-2.0.x can not really help us in this case, so we
will have to perform some magic tricks with the libfoo.a symbols to help
the linker to the right thing.

2. We link a static binary. libc.a does not export the old fopen
interfaces anymore, so we need to have those provided in the libcompat
library and we need to add -lcompat-2.0.x to the list of the libs linked
in. But if libcompat-2.0.x.a redefines fopen the we run into the
possiblity that another library that we might use which is compiled
against glibc 2.1 and which is referencing fopen will cause the linking
stage to produce the wrong result and be again a fatal move. Again,
renaming the symbols in the libfoo.a to follow a different convention is a
solution for the problem. fopen@GLIBC_2.0 might save it again.

So, given this blurb of mine, does anyone see a problem with this
scenario? Does anyone have better ideas?

Thanks,

Cristian
--
----------------------------------------------------------------------
Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]