Re: .rem .div .mul ... in glibc-2.1

[Juan Cespedes <cespedes@debian.org>]

On Fri, Jan 23, 1998 at 02:44:54PM +0100, Eric Delaunay wrote:
> Juan Cespedes wrote:
> >         Why aren't .[u]{div,rem,mul} defined as global in glibc-2.1?
> > Is there a good reason for this?
> > 
> > 	I think they should be added to `libc.map' in the glibc
> > sources to declare them as global.  If not, some programs may not work
> > (in fact, they don't work now).
> 
> 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 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.

> Can you try to replace libm.so link with this script:
> 
> GROUP ( /lib/libm.so.6 /usr/lib/libc.a )

	I think that won't work.  Think about it.

-- 
Juan Cespedes


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