p5pRT
commented
7 years ago From kabel@blackhole.sk
Created by kabel@blackhole.sk
When coreutils are compiled with multicall support\, the command ls -l /proc/self/exe outputs something like:
lrwxrwxrwx 1 user group 0 Jan 1 00:00 /proc/self/exe -> /usr/bin/coreutils
But when determining the HAS_PROCSELFEXE macro\, perl's Configure script checks if the result of the ls command contains string '/ls'. It this case this fails\, because there is no /bin/ls\, rather /usr/bin/coreutils.
Thus when perl is compiled on systems with multicall coreutils\, it cannot check the path to its own executable\, and thus the $^X variable return argv[0].
I encountered this issue when compiling OpenWRT/LEDE on my Gentoo system with multicall coreutils: when perl is cross compiled\, miniperl is just a symlink to host's perl\, which\, in this case\, is built to be relocatable. But the code which searches for modules could not find the XXX/usr/lib/perl5 directory\, because instead of "XXX/usr/bin/perl"\, it had just "./miniperl" in $^X.
I think the best way to check for /proc/self/exe and similar symlinks in Configure would be to compile a small test.c which check for this\, ie. something like
#include \<unistd.h> int main(int argc\, char ** argv) { char r[1024]; size_t l = readlink(argv[1]\, r\, 1024); return l \< 1024 && !strcmp(r\, argv[2])); }
Then Configure could just call /PATH/test /proc/self/exe /PATH/test to check if /proc/self/exe works as intended.
zwizwa
jkeenan
Migrated from rt.perl.org#130997 (status was 'open')
Searchable as RT130997$