Re: library reduction problems in recent rootdisk.sh
Ethan Benson <erbenson@alaska.net> writes:
> On Tue, Nov 13, 2001 at 12:43:03PM +0100, Goswin Brederlow wrote:
> > It looks eigther like a gcc bug or the atexit symbol is defined in a
> > strange way that prevents it from resolving in the stripped version of
> > the libc.
> >
> > Can someone with this problem try to run the library reduction on
> >
> > #include <stdlib.h>
> > void bla(void) {}
> > int main() {
> > atexit(bla);
> > return 0;
> > }
> >
> > and the libc with nothing else cluttering the output.
> >
> > Its the same behaviour the broken libc had on i386.
>
> i just tried both your test and a full powerpc b-f build and this time
> i had no problems with mklibs.py. libc6 is 2.2.4-5
fine. So alpha, ppc, i386 and m68k work. Anyone other experiences?
> we still cannot use mklibs.py until someone fixes the gratuitous
> i386ism regarding what ld is called i have to use the following patch
> to make it work correctly (well ignore DEBUG_SPAM):
>
> Index: scripts/rootdisk/mklibs.py
> ===================================================================
> RCS file: /cvs/debian-boot/boot-floppies/scripts/rootdisk/mklibs.py,v
> retrieving revision 1.4
> diff -u -r1.4 mklibs.py
> --- scripts/rootdisk/mklibs.py 2001/08/11 06:55:18 1.4
> +++ scripts/rootdisk/mklibs.py 2001/11/13 15:14:55
> @@ -53,7 +53,7 @@
> DEBUG_VERBOSE = 2
> DEBUG_SPAM = 3
>
> -debuglevel = DEBUG_NORMAL
> +debuglevel = DEBUG_SPAM
>
> def debug(level, *msg):
> if debuglevel >= level:
> @@ -352,7 +352,7 @@
> base_name = so_pattern.match(library).group(1)
> # libc needs its soinit.o and sofini.o as well as the pic
> if base_name == "libc":
> - extra_flags = find_lib("ld-linux.so.2")
> + extra_flags = find_lib("ld.so.1")
> extra_pre_obj = "/usr/lib/libc_pic/soinit.o"
> extra_post_obj = "/usr/lib/libc_pic/sofini.o"
> else:
> @@ -396,6 +396,6 @@
> os.remove(dest_path + "/" + lib)
>
> # Make the dynamic linker executable
> -ld_file = find_lib("ld-linux.so.2")
> +ld_file = find_lib("ld.so.1")
> ld_file_name = os.path.basename(ld_file)
> os.chmod(dest_path + "/" + ld_file_name, 0755)
I have the following on my system:
mrvn@dual:~% ls -l /lib/ld*
-rwxr-xr-x 1 root root 94561 Oct 30 23:44 /lib/ld-2.2.4.so*
lrwxrwxrwx 1 root root 18 Mar 13 2001 /lib/ld-linux.so.1 -> ld-linux.so.1.9.11*
-rwxr-xr-x 1 root root 24817 Mar 7 2001 /lib/ld-linux.so.1.9.11*
lrwxrwxrwx 1 root root 11 Nov 4 05:54 /lib/ld-linux.so.2 -> ld-2.2.4.so*
-rwxr-xr-x 2 root root 99568 Mar 7 2001 /lib/ld.so*
-rwxr-xr-x 2 root root 99568 Mar 7 2001 /lib/ld.so.1.9.11*
2fca30cbaccb4c9eccfe46cc26d1317b /lib/ld-2.2.4.so
d4a2c961c9306a2e556aa01b9f3578a8 /lib/ld-linux.so.1.9.11
77328b80b0c4956fa82bbec45cfd8fd1 /lib/ld.so
77328b80b0c4956fa82bbec45cfd8fd1 /lib/ld.so.1.9.11
So which one should be used? Which ones don't work?
Do all archs have an /lib/ld.so and does that work for all?
I would hate to do things differently for each arch or libc version. I
thought with ld-linux.so.2 would be provided by all current glibcs.
May the Source be with you.
Goswin
Reply to: