Re: bug report...

On Sun, Jul 18, 1999 at 08:16:41PM -0500, Stephen Langasek wrote: > On Mon, 19 Jul 1999, Sascha Schumann wrote: > > > > I've found that a generic workaround is to explicitly link against libc > > > when compiling. This forces the symbol versions to be resolved at link > > > time, bypassing the libdl bugginess. > > > Could you elaborate? > > glibc 2.1.1 contains two versions of the 'fclose' symbol: fclose@GLIBC_2.0, > and fclose@@GLIBC_2.1. When linking against libc, references to fclose will > be resolved to one of these two versions. Normally, this will mean > resolving to the default of fclose@@GLIBC_2.1, and this is the symbol that > will be stored in the object output. > > If -lc is not included explicitly in a linker line, and the target is a > shared object, this resolution won't take place. The symbol name stored in > the object output will be 'fclose', and this is left to be resolved at > runtime (or perhaps at a further linking stage?). Whatever hints are used > for resolving if the object is dlopen()ed, they lead to choosing the wrong > version for fclose. That was our problem (see libc bug report #1208 for the details). > > > H.J. Lu has to say something interesting about the link problem. > > It might also affect your case: > > > Never, never, never, never call "ld" directly to generate DSO > > unless you know what you are doing. You should use "gcc -shared" > > instead of "ld -Bshareable". Please read > > Well, I always thought I knew what I was doing, but it looks like the rules > may have changed :) That's apparantly the case. -- Regards, Sascha Schumann Consultant