symlinks the following symlinks as dangling: dangling: /bin/zfgrep -> zgrep dangling: /bin/zegrep -> zgrep dangling: /bin/zcmp -> zdiff Reproducible: Always Steps to Reproduce: 1. extract a stage into a dummy directory 2. ls -l bin/zfgrep bin/zegrep bin/zcmp lrwxrwxrwx 1 root root 5 2007-06-10 17:51 bin/zcmp -> zdiff lrwxrwxrwx 1 root root 5 2007-06-10 17:51 bin/zegrep -> zgrep lrwxrwxrwx 1 root root 5 2007-06-10 17:51 bin/zfgrep -> zgrep 3. # which zgrep zdiff /usr/bin/zgrep /usr/bin/zdiff 4. links should point to ../usr/bin/zgrep and ../usr/bin/zdiff
OK. Which stages, exactly?
I found them in : stage1-x86-2007.0.tar.bz2 stage1-x86-hardened-2.6-2007.0.tar.bz2 stage1-amd64-2007.0.tar.bz2 stage1-amd64-hardened-2007.0.tar.bz2 So I figured it probably affected more than just those stages.
Thanks, that gives me a starting place to try to track down the root cause of the problem. Danny, Andrew, Christian: What machines did you build your release media on for 2007.0? I'm guessing this is probably an artifact of some version change between our initial and final snapshots, causing the location to move, but I'd like to make sure it isn't catalyst.
The x86 build was done on my home machine. The amd64 build was done on poseidon (afaik). I believe the hardened builds were done on miranda. Also, I don't think it can be a snapshot change as I did a cacheless rebuild of all the (non-hardened) x86 media near the end of the release cycle. It may be a problem with the ebuild in whatever version is in the release. In my local version of gzip (1.3.12), those symlinks have been replaced with wrapper scripts that call the other utility.
Is this still an issue with 2008.0?
on the i686 stage 3 (stage3-i686-2008.0.tar.bz2 md5:2076...d435) i found this: dangling: /usr/i486-pc-linux-gnu/lib/libopcodes.la -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libopcodes.la dangling: /usr/i486-pc-linux-gnu/lib/libopcodes.so -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libopcodes.so dangling: /usr/i486-pc-linux-gnu/lib/libopcodes-2.18.so -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libopcodes-2.18.so dangling: /usr/i486-pc-linux-gnu/lib/ldscripts -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/ldscripts dangling: /usr/i486-pc-linux-gnu/lib/libopcodes.a -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libopcodes.a dangling: /usr/i486-pc-linux-gnu/lib/libiberty.a -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libiberty.a dangling: /usr/i486-pc-linux-gnu/lib/libbfd.a -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libbfd.a dangling: /usr/i486-pc-linux-gnu/lib/libbfd-2.18.so -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libbfd-2.18.so dangling: /usr/i486-pc-linux-gnu/lib/libbfd.la -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libbfd.la dangling: /usr/i486-pc-linux-gnu/lib/libbfd.so -> /usr/lib/binutils/i486-pc-linux-gnu/2.18/libbfd.so marsupilami / # ls /usr/lib/binutils/ i686-pc-linux-gnu
Those are probably just artifacts from the move from i486 to i686 CHOST when the i686 stages were built from the x86 stage1. Those files are probably created by gcc-config or binutils-config. Do the files referenced by the original reporter still exist?
nope! i didnt check the amd64 image though - but it wasnt on x86 or i686. thanks..
