This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: Symbol versioning question
- To: hjl@lucon.org (H.J. Lu)
- Subject: Re: Symbol versioning question
- From: Steve Dunham <dunham@cse.msu.edu>
- Date: 21 Dec 1998 12:27:26 -0500
- Cc: libc-hacker@cygnus.com (GNU C Library)
- References: <m0zrztV-00038vC@ocean.lucon.org>
hjl@lucon.org (H.J. Lu) writes:
> > The specific problem here is that _shared libraries_ compiled with
> > glibc 2.0 (or older version of glibc 2.1) can't be used to compile new
> > programs with glibc 2.1.
> Can you show me a simple example? I mean between glibc 2.0 and 2.1,
> not between 2.1s.
I don't have a 2.0 lying around, but the following would reproduce the
problem, if it exists. (I think this problem would show up if and
only if the glibc 2.0 library has symbol versioning turned on. It only
occurs when you link the shared library against libc - so it can pick
up the versions.)
This example will happen between any two versioned C libraries where
popen() has different version numbers.
Compile the following library against glibc 2.0:
library.c:
void foo() {popen();}
gcc -shared library.c -o library.so -lc
^^^
important
Then switch to glibc 2.1 and try to link it with something:
main.c:
int main() {}
gcc -o main main.c -L. -lrary
And I get:
./library.so: undefined reference to `popen@@GLIBC_2.0'
Steve
dunham@cse.msu.edu