Summary: | sys-apps/pciutils-3.7.0 - x86_64-pc-linux-gnu/bin/ld: cannot find -ludev | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Martin Mokrejš <mmokrejs> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ionen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin Mokrejš
2021-03-17 14:08:01 UTC
pciutils[udev] seems fine on my own amd64 prefix, and the linking line is identical. But when I look at the libudev.so symlink I do feel like something "could" go wrong. Target exists but for me it's a whole: libudev.so -> ../../../../../home/ionen/prefix/lib64/libudev.so.1.6.3 Is it valid for you? Thank you. Right, on the very same machine the ls(1) output blinks the symlink on 3rd line in red, as it points to nowhere: lrwxrwxrwx 1 mmokrejs meta 16 Mar 17 14:44 /storage/brno3-cerit/home/mmokrejs/gentoo/lib64/libudev.so.1 -> libudev.so.1.6.3 -rwxr-xr-x 1 mmokrejs meta 189808 Mar 17 14:44 /storage/brno3-cerit/home/mmokrejs/gentoo/lib64/libudev.so.1.6.3 lrwxrwxrwx 1 mmokrejs meta 84 Mar 17 14:44 /storage/brno3-cerit/home/mmokrejs/gentoo/usr/lib64/libudev.so -> ../../../../../../../storage/brno3-cerit/home/mmokrejs/gentoo/lib64/libudev.so.1.6.3 -rw-r--r-- 1 mmokrejs meta 655 Mar 17 14:44 /storage/brno3-cerit/home/mmokrejs/gentoo/usr/lib64/pkgconfig/libudev.pc $ cd /storage/brno3-cerit/home/mmokrejs/gentoo/usr/lib64/ $ ls -latr libudev.so lrwxrwxrwx 1 mmokrejs meta 84 Mar 17 14:44 libudev.so -> ../../../../../../../storage/brno3-cerit/home/mmokrejs/gentoo/lib64/libudev.so.1.6.3 $ file libudev.so libudev.so: broken symbolic link to ../../../../../../../storage/brno3-cerit/home/mmokrejs/gentoo/lib64/libudev.so.1.6.3 $ The real fs mount point is /mnt/storage-brno3-cerit, then /storage/brno3-cerit symlinks to /mnt/storage-brno3-cerit/nfs4 I assume it is because the path when resolved with the "nfs4" in its name is longer by one. I guess during libudev install the ... libtool? package create the path when think it is under /mnt/storage-brno3-cerit/nfs4 path while later it get executed through /storage/brno3-cerit path. But why does this happen only for a single package? Maybe the error message from bootstrap-prefix.sh was :correct"? $ export I_KNOW_MY_GCC_WORKS_FINE_WITH_SYMLINKS='hell yeah' $ ./bootstrap-prefix.sh The "problem is" that the mounts are done in a different way on the cluster and that is why there is a unified symlinked path as e.g. /storage/brno3-cerit and that was the one I wanted to tell gentoo-prefix to pick. All tools works IMO except this one. In your case I suggest to just fix the symlink manually, because this really is nasty to take care of. Hence we don't support this setup. Maybe readlink or some other utility could be used or improved to shorten the path? Now on the broken symlink it cannot probably do any better but during installation of libudev it could have shortened the relative path to ../../lib64/libudev.so.1.6.3 $ readlink libudev.so ../../../../../../../storage/brno3-cerit/home/mmokrejs/gentoo/lib64/libudev.so.1.6.3 $ rm libudev.so; ln -s ../../lib64/libudev.so.1.6.3 libudev.so rm libkmod.so; ln -s ../../lib64/libkmod.so.2.3.6 libkmod.so # from sys-apps/kmod-28 There were no more issues. I tested like this: $ ln -s ../dsdsd/sds junksss $ find ./ -type l -exec file {} \; | grep broken ./junksss: broken symbolic link to ../dsdsd/sds $ Maybe some portage class could have taken care of this? Still I wonder why this happened for only two packages. |