I have recently been trying to get the ARM D-I port underway and have come across an issue which I cant figure out who to assign the bug ;-) against. The "discover" udeb package contains the discover dynamic libraries, some symlinks to those libraries and the discover binary. The files are specificly: -rw-r--r-- root/root 67420 2003-12-13 20:43:46 ./lib/libdiscover.so.1.0.0 -rwxr-xr-x root/root 11264 2003-12-13 20:43:46 ./sbin/discover lrwxrwxrwx root/root 0 2003-12-13 20:43:43 ./lib/libdiscover.so -> libdiscover.so.1.0.0 lrwxrwxrwx root/root 0 2003-12-13 20:43:43 ./lib/libdiscover.so.1 -> libdiscover.so.1.0.0 This is the same payload as all the other architectures which have this udeb (x86, ppc etc.). When the d-i build is run (I am currently using "fakeroot make image") all proceeds ok untill the library reduction step. After the final reduction pass mklibs moves the library files to their final names. The relevant faliure is: Moving libdiscover.so.1.0.0 to libdiscover.so.1. Moving libc.so.6 to libc.so.6. Moving libdebconfclient.so.0 to libdebconfclient.so.0. Moving libdl.so.2 to libdl.so.2. Moving libdebian-installer.so.4 to libdebian-installer.so.4. Moving libm.so.6 to libm.so.6. Moving libgcc_s.so.1 to libgcc_s.so.1. Moving ld-linux.so.2 to ld-linux.so.2. Command failed with status 1 : readelf --all -W ./tmp/cdrom/tree/lib/libdiscover.so With output: readelf: Error: Cannot stat input file ./tmp/cdrom/tree/lib/libdiscover.so. What is happening here is that the first move which changes libdiscover.so.1.0.0 to libdiscover.so.1 does two things removes the libdiscover.so.1 symlink by overwiting it, which is ok, and secondly breaks the libdiscover.so symlink as the target is no longer there. Thus mklibs then tries to perform a readelf on a broken link and the library reduction fails. This does not fail on other platforms (examined build logs for x86 and ppc) because of an ordering change, the move of the libdiscover.so.1.0.0 to libdiscover.so.1 is performed *after* the libdiscover.so symlink has been moved to libdiscover.so.1 hence all the symlinks stay correct and finally ending up moving the real file and destroying all the symlinks. Having explained all that I need help, I have a workround of simply removing the symlinks from the libdiscover udeb (this works for ARM) but is taht correct and if so do I file a bug against discover? or is this a mklibs error as it shouldnt try to reference a symlink and hence taht needs a bug? or is it a case of I need to figure out why the ordering is wrong on ARM? (I have been at this for three days now :-( -- Regards Vincent http://www.kyllikki.org/
Attachment:
signature.asc
Description: Digital signature