Juan Cespedes wrote: > > My first attempt (a while ago) to build glibc was to add such entries in the > > libc.map because I got some undefined symbols at link time. It was wrong. > > I > > didn't realized that libc.so should not be a soft link to libc.so.6 but have > > to be a script that tells the linker to use the dynamic library first, then > > the static one to resolve undefined symbols in the former. > > Why was it wrong?
I thought it was wrong because when I removed the soft link I created by mistake with the script provided with glibc, everything worked well. > I see two problems if we leave those symbols undefined: > > 1) Some of them are defined in ld-linux.so.2, because they are used there: > > $ nm -D /lib/ld-linux.so.2 | grep ' \.' > > 000127bc T .div > > 00012a64 T .udiv > > 000126c4 T .umul > > 00012cdc T .urem > And, see this: > > $ cat /usr/lib/libc.so > > /* GNU ld script > > Use the shared library, but some functions are only in > > the static library, so try that secondarily. > > The dynamic linker defines some functions used by libc.so.6, > > but ld uses definitions from libc.a before examining the > > dependencies of libc.so.6 to find ld-linux.so.2. */ > > GROUP ( /lib/libc.so.6 /lib/ld-linux.so.2 /usr/lib/libc.a ) > So, if my program (`hello') uses `.div', at build time gcc searches > first in libc.so.6; it isn't there. Then, it finds in ld-linux.so.2 > and volia! it's there, and that symbol is declared as `undefined'. > But, if two releases of the glibc later, ld-linux doesn't need `.div' > anymore, it would be out of that library and my program would say > `undefined symbol'. > > 2) Let's suppose you write a program which uses some symbol from libm, > which in fact uses some of these symbols (eg, `.umul'). At build time, > that symbol will be found in libc.a and it will be included in the > executable. But what would happen if two releases of the glibc later, > that symbol from libm does not only use `.umul', but also `.mul'? You > will have one undefined symbol that the interpreter won't be able to > resolve. > > So, I see one of these solutions: > 1) Define them as global in libc.so.6 (adding them to libc.map) > 2) Leave them only in libc.a, *and* make them local in ld-linux.so.2 > *and* include them as local in libm.so.6 > > I think the former is the best one. Ok, you convince me. Is there other symbols, either in ld-linux or libm, which could cause the same problem in later release? -- Eric Delaunay | "La guerre justifie l'existence des militaires. [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
