Re: bug report...

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. > 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 :) -Steve Langasek postmodern programmer