Re: .rem .div .mul ... in glibc-2.1
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.
delaunay@lix.polytechnique.fr | En les supprimant." Henri Jeanson (1900-1970)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-sparc-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: