Open kentfredric opened 4 years ago
On Sun, 17 May 2020 22:23:58 -0700, Kent Fredric notifications@github.com wrote:
Description We have developers on Gentoo testing some unusual setups, particularly:
- There is no
/usr/bin/gcc
,/usr/bin/cc
or/usr/bin/ar
- There is no
gcc
,cc
orar
in$PATH
AR=
andCC=
are both defined with correct values.Under this configuration, perl .
/configure
fails to detect a correctar
, and later, embedsar = ar
inConfig_heavy.pl
However, this failure does not stop perl from compiling, but it does make ExtUtils-MakeMaker's test suite to fail in
02xs-dynamic.t
, and all EUMM based XS packages generate a makefile with:AR = ar
And afterwards, assuming you installed it regardless of test failure ( or even not running tests ), this eventually leads to breaking anything that consumes
$Config{ar}
expecting it to be thear
used to build "Perl itself" ( which is impossible, such a thing asar
didn't exist when Perl was built ).
Your case seems clear, so the question that remains is: are cc and are the only two, or is it also others, like nm and ranlib?
If we have a defined set, would this mean that we can leave everything in place until the very last step where just before we set AR to 'ar' we should check if $AR is set to anything and use that instead. In sh talk
AR=ar
→
AR=${AR:-ar}
However, there is a good workaround, as long as one invokes
./configure
with:-Dar=x86_64-pc-linux-gnu-ar
Interestingly, ar is set this way under crosscompiling
(Or similar as appropriate for the target, just keep in mind this may not even be a gcc/binutils ar, but one provided by the llvm project)
Then it JustWorks:
- The aformentioned MakeMaker tests pass
- No new test failures occur
- Subsequent EUMM XS builds have a valid value for
AR =
- Large volumes of EUMM XS builds then work
So it seems this is just an inadequacy in Config not detecting AR appropriately, and also not bailing as appropriate when it would generate a bogus configuration.
Perl configuration
Your case seems clear, so the question that remains is: are cc and are the only two, or is it also others, like nm and ranlib?
There are others, but its not clear.
For instance, the same is happening with "ld", but I'm nowhere going to touch that one because too much perl code expects "ld" to be a ccld, not an actual "ld".
I'm sure eventually nm and ranlib may also be done this way, but our tester is starting out simple (for the most part, the end goal is to mimic non-gnu/linux platforms or cross-development tooling while still being run on a more popular architecture ).
I'm sure eventually I'll get bugs filed about code directly trying to invoke /usr/bin/ranlib , or something, just it hasn't happened yet.
Just got some more output from our tester.
The mention of gcc and cpp here are a little weird as we do pass -Dcc=, but perhaps some love is needed for G++ / CXX
As for LD, here's some background on why I'm not touching it with a barge pole:
Simply setting "LD=path/to/an/ld" breaks perl code, and has perl code authors telling you that you're wrong to set LD to an LD , ....
https://rt.cpan.org/Public/Bug/Display.html?id=120907 https://bugs.gentoo.org/641054
ld handling is a complete shit-show and I'm too afraid to touch it.
Further testing:
Building perl with -Dld=path/to/actual/ld breaks perl building:
cp DynaLoader.o ../../DynaLoader.o
make[1]: Leaving directory '/var/tmp/portage/dev-lang/perl-5.30.2-r1/work/perl-5.30.2/ext/DynaLoader'
rm -f libperl.so.5.30.2
x86_64-pc-linux-gnu-ld -o libperl.so.5.30.2 -shared -O2 -pipe -mtune=native -march=native -fstack-protector-strong -fno-stack-protector -Wl,-O1 -Wl,--as-needed -fstack-protector-strong -fno-stack-protector -Wl,-soname -Wl,libperl.so.5.30 op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o DynaLoader.o -ldl -lm -lcrypt -lutil -lc
x86_64-pc-linux-gnu-ld: unrecognised emulation mode: arch=native
Supported emulations: aix5ppc aix5rs6 aixppc aixrs6 alpha alphavms arcv2elf arcv2elfx arcelf arclinux arclinux_nps arm_wince_pe armelf armelf_fbsd armelf_fuchsia armelf_linux armelf_linux_eabi armelf_linux_fdpiceabi armelf_nacl armelf_nbsd armelf_phoenix armelf_vxworks armelfb armelfb_fbsd armelfb_fuchsia armelfb_linux armelfb_linux_eabi armelfb_linux_fdpiceabi armelfb_nacl armelfb_nbsd armnto armpe armsymbian avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1 avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny crisaout criself crislinux cskyelf cskyelf_linux d10velf d30v_e d30v_o d30velf elf32_dlx elf32_sparc elf32_sparc_sol2 elf32_sparc_vxworks elf32_spu elf32_tic6x_be elf32_tic6x_le elf32_tic6x_linux_be elf32_tic6x_linux_le elf32_tic6x_elf_be elf32_tic6x_elf_le elf32am33lin elf32bfin elf32bfinfd elf32cr16 elf32crx elf32epiphany elf32epiphany_4x4 elf32fr30 elf32frv elf32frvfd elf32ft32 elf32ip2k elf32iq10 elf32iq2000 elf32lm32 elf32lm32fd elf32lppc elf32lppclinux elf32lppcnto elf32lppcsim elf32m32c elf32mb_linux elf32mbel_linux elf32mcore elf32mep elf32metag elf32microblazeel elf32microblaze elf32moxie moxiebox elf32mt elf32or1k elf32or1k_linux elf32ppc elf32ppc_fbsd elf32ppclinux elf32ppcnto elf32ppcsim elf32ppcvxworks elf32ppcwindiss elf32lriscv elf32lriscv_ilp32f elf32lriscv_ilp32 elf32rl78 elf32rx elf32tilegx elf32tilegx_be elf32tilepro elf32vax elf32visium elf32xc16x elf32xc16xl elf32xc16xs elf32xstormy16 elf32xtensa elf32z80 elf_i386 elf_i386_be elf_i386_fbsd elf_i386_ldso elf_i386_nacl elf_i386_sol2 elf_i386_vxworks elf_iamcu elf_s390 h8300elf h8300elf_linux h8300helf h8300helf_linux h8300hnelf h8300self h8300self_linux h8300snelf h8300sxelf h8300sxelf_linux h8300sxnelf hppaelf hppalinux hppanbsd hppaobsd i386beos i386bsd i386go32 i386lynx i386moss i386msdos i386nto i386pe i386pe_posix m32relf m32relf_linux m32rlelf m32rlelf_linux m68hc11elf m68hc11elfb m68hc12elf m68hc12elfb m68kelf m68kelfnbsd m9s12zelf mcorepe mn10200 mn10300 msp430elf msp430X nds32elf nds32elf16m nds32elf_linux nds32belf nds32belf16m nds32belf_linux ns32knbsd nios2elf nios2linux pc532macha pdp11 pjelf pjlelf ppclynx ppcmacos ppcpe pruelf score3_elf score7_elf sh shelf shelf_fd shelf_linux shelf_nbsd shelf_nto shelf_uclinux shelf_vxworks shl shlelf shlelf_fd shlelf_linux shlelf_nbsd shlelf_nto shlelf_vxworks shpe tic30aout tic30coff tic3xcoff tic3xcoff_onchip tic4xcoff tic54xcoff v850 v850_rh850 vanilla vaxnbsd xgateelf z80 z8001 z8002 aarch64elf aarch64elf32 aarch64elfb aarch64elf32b aarch64cloudabi aarch64cloudabib aarch64fbsd aarch64fbsdb aarch64linux aarch64linuxb aarch64linux32 aarch64linux32b elf32_x86_64 elf32_x86_64_nacl elf32b4300 elf32bmip elf32bmipn32 elf32bsmip elf32btsmip elf32btsmip_fbsd elf32btsmipn32 elf32btsmipn32_fbsd elf32ebmip elf32ebmipvxworks elf32elmip elf32elmipvxworks elf32l4300 elf32lmip elf32lr5900 elf32lr5900n32 elf32lsmip elf32ltsmip elf32ltsmip_fbsd elf32ltsmipn32 elf32ltsmipn32_fbsd elf32mipswindiss elf64_aix elf64bpf elf64_ia64 elf64_ia64_fbsd elf64_ia64_vms elf64_s390 elf64_sparc elf64_sparc_fbsd elf64_sparc_sol2 elf64alpha elf64alpha_fbsd elf64alpha_nbsd elf64bmip elf64btsmip elf64btsmip_fbsd elf64hppa elf64lppc elf64lriscv elf64lriscv_lp64f elf64lriscv_lp64 elf64ltsmip elf64ltsmip_fbsd elf64mmix elf64ppc elf64ppc_fbsd elf64rdos elf64tilegx elf64tilegx_be elf_l1om elf_l1om_fbsd elf_k1om elf_k1om_fbsd elf_x86_64 elf_x86_64_cloudabi elf_x86_64_fbsd elf_x86_64_nacl elf_x86_64_sol2 hppa64linux i386pep mmo
make: *** [makefile:340: libperl.so.5.30.2] Error 1
make: *** Waiting for unfinished jobs....
This is despite this output:
Any additional ld flags (NOT including libraries)? [-Wl,-O1 -Wl,--as-needed -fstack-protector-strong -fno-stack-protector]
But this looks bad:
What command should be used to create dynamic libraries? [x86_64-pc-linux-gnu-ld]
Any special flags to pass to x86_64-pc-linux-gnu-ld to create a dynamically loaded library? [-shared -O2 -pipe -mtune=native -march=native -fstack-protector-strong -fno-stack-protector]
Any special flags to pass to x86_64-pc-linux-gnu-gcc to use dynamic linking? [-Wl,-E]
ld supports scripting
https://metacpan.org/source/SHAY/perl-5.30.2/hints/linux.sh#L166-179
if [ -x /usr/bin/gcc ] ; then
gcc=/usr/bin/gcc
else
gcc=gcc
fi
case "$plibpth" in
'') plibpth=`LANG=C LC_ALL=C $gcc $ccflags $ldflags -print-search-dirs | grep libraries |
cut -f2- -d= | tr ':' $trnl | grep -v 'gcc' | sed -e 's:/$::'`
set X $plibpth # Collapse all entries on one line
shift
plibpth="$*"
;;
esac
Well that's annoying.
Description We have developers on Gentoo testing some unusual setups, particularly:
/usr/bin/gcc
,/usr/bin/cc
or/usr/bin/ar
gcc
,cc
orar
in$PATH
AR=
andCC=
are both defined with correct values.Under this configuration, perl .
/configure
fails to detect a correctar
, and later, embedsar = ar
inConfig_heavy.pl
However, this failure does not stop perl from compiling, but it does make ExtUtils-MakeMaker's test suite to fail in
02xs-dynamic.t
, and all EUMM based XS packages generate a makefile with:And afterwards, assuming you installed it regardless of test failure ( or even not running tests ), this eventually leads to breaking anything that consumes
$Config{ar}
expecting it to be thear
used to build "Perl itself" ( which is impossible, such a thing asar
didn't exist when Perl was built ).However, there is a good workaround, as long as one invokes
./configure
with:(Or similar as appropriate for the target, just keep in mind this may not even be a gcc/binutils ar, but one provided by the llvm project)
Then it JustWorks:
AR =
So it seems this is just an inadequacy in Config not detecting AR appropriately, and also not bailing as appropriate when it would generate a bogus configuration.
Perl configuration