Re: Symbol versioning question

[hjl@lucon.org (H.J. Lu)]

> 
> 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

There is no symbol versioning in glibc 2.0 at all. You must be using
an earlier glibc 2.1.

> 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

That is not a problem since "gcc -shared" will always add -lc if
you use egcs. BTW, gcc should not be used on Linux, except for
compiling kernels, where you may use gcc 2.7.2.x. FWIW, I have been
using egcs on kernels without much problems.

> 
> 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'
> 
> 

I have no problems with your testcase between glibc 2.0 and 2.1.
But I do know there is a problem between 2.1s. Please make sure
you can reproduce it before you report a bug.

Thanks.



-- 
H.J. Lu (hjl@gnu.org)