source='pcrecpp.cc' object='pcrecpp.lo' libtool=yes \ DEPDIR=.deps depmode=sgi /bin/sh ./depcomp \ /bin/sh ./libtool --tag=CXX --mode=compile CC -DHAVE_CONFIG_H -I. -I/opt/portage/usr/include -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -c -o pcrecpp.lo pcrecpp.cc CC -DHAVE_CONFIG_H -I. -I/opt/portage/usr/include -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -c pcrecpp.cc -Wp,-MDupdate,.deps/pcrecpp.TPlo -DPIC -o .libs/pcrecpp.o cc-1020 CC: ERROR File = pcrecpp.cc, Line = 776 The identifier "strtoll" is undefined. long long r = strtoll(str, &end, radix); ^ cc-1020 CC: ERROR File = pcrecpp.cc, Line = 806 The identifier "strtoull" is undefined. unsigned long long r = strtoull(str, &end, radix); ^ 2 errors detected in the compilation of "pcrecpp.cc". make[1]: *** [pcrecpp.lo] Error 1 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/dev-libs/libpcre-7.6/work/pcre-7.6' make: *** [all] Error 2 * ERROR: dev-libs/libpcre-7.6 failed: * emake failed * * Call stack: * ebuild.sh: 46: <call src_compile> * environment:2378: emake all || die "emake failed" Rebuilding with CC='CC' doesn't seem to help... although it does looks as if 'strtoll' is C99 only, and so not available in C++ - so I imagine that the problem is again that configure (invoking 'cc') thinks a function is defined when it isn't (when the code is actually built with 'CC')... is there any way to patch configure from ebuilds to prevent this? It looks as if the only solution is to undef HAVE_LONG_LONG and HAVE_UNSIGNED_LONG_LONG if USE="cxx" (although this might have a detrimental effect on the (non-C++) remainder of the code) P.S. *Everything* that uses libtool seems to invoke "/bin/sh ./libtool", which is distinctly non-prefix friendly. Can anything be done about this? With USE="cxx" libpcre merges correctly.
(In reply to comment #0) [snip] > Rebuilding with CC='CC' doesn't seem to help... although it does looks as if > 'strtoll' is C99 only, and so not available in C++ - so I imagine that the > problem is again that configure (invoking 'cc') thinks a function is defined > when it isn't (when the code is actually built with 'CC')... is there any way > to patch configure from ebuilds to prevent this? There are currently libtool patches to do things, maybe that can also be done for configure. But can't we set some environment (CC?) in the profile to make it work without patching? > It looks as if the only solution is to undef HAVE_LONG_LONG and > HAVE_UNSIGNED_LONG_LONG if USE="cxx" (although this might have a detrimental > effect on the (non-C++) remainder of the code) Interix (Windows) doesn't have strtoll Darwin does have strtoll Solaris does have strtoll cant we export ac_have_strtoll=no or something to force configure using replacement code? > P.S. *Everything* that uses libtool seems to invoke "/bin/sh ./libtool", which > is distinctly non-prefix friendly. Can anything be done about this? This is use of SHELL in Makefiles. Maybe if we patch emake to pass SHELL=..., alternatively CONFIG_SHELL (for autoconfed projects) should set SHELL to that value as well, iirc. For IRIX we probably want to set the latter in the profile anyway.
(Apologies - please be prepared for a stream-of-consciousness type comment... I'm writing this as I try to debug the build ;) 'ac_cv_func_strtoll=no'? Trying now... (I also had to set 'lt_cv_prog_compiler_c_o=yes' and 'lt_cv_prog_compiler_c_o_CXX=yes' to build correctly - but I think that's because libpcre's libtool doesn't like the debug output from my wrapper script, when enabled. No other build encountered thus far suffers from this issue...) Hmm - now the compilation succeeded, but the link-stage failed claiming not to be able to find a library for '-lbz2' - this is because libpcre doesn't supply a '-L' option to tell the linker where to look for libraries and my wrapper script only appends these options if not present - to do otherwise is probably potentially dangerous (I guess that it'd be possible to detect every DSO specified on the command-line, check for where on the filesystem it lives, and add a -L option for it. It might be easier still to assume that libraries will either be in one of $EPREFIX/usr/lib or $EPREFIX/lib or in a system path, and so insert the $EPREFIX path before *any* -l option...) Exporting 'LIBS="-L${EPREFIX}/usr/lib -L${EPREFIX}/lib -lz -bz2"' resolves this problem. Okay - after linking there's more building: I'm hitting the #error directive at pcrecpp.cc line 788 The problem is that even though config.log confirms that it now doesn't think that I have strtoll(), I've still got HAVE_LONG_LONG. So it looks as if 'ac_cv_type_long_long=no' and 'ac_cv_type_unsigned_long_long=no' are required, because if you have long longs, then one of the {strtoq(),strtoll(),strtoi64()} functions are required, or else the build aborts :( It doesn't look as if anything is lost by removing long long support, though - it only appears in the C++ parts, and the alternative is to build with USE="-cxx". In the end, the package compiled and passed all 5 tests :) The final command-line required to do this was: ac_cv_func_strtoll=no lt_cv_prog_compiler_c_o=yes lt_cv_prog_compiler_c_o_CXX=yes LIBS="-L/opt/portage/usr/lib -L/opt/portage/lib -lz -lbz2" ac_cv_type_long_long=no ac_cv_type_unsigned_long_long=no FEATURES="test" USE="cxx" emerge -v libpcre Phew! P.S. Setting CONFIG_SHELL did result in the prefix shell being used
Same problem in libpcre-7.7: please could the ebuild be patched to add the following options for IRIX: ac_cv_func_strtoll=no # C99 only lt_cv_prog_compiler_c_o=yes # See note 1 lt_cv_prog_compiler_c_o_CXX=yes # See note 1 ac_cv_type_long_long=no # So that missing strtoll doesn't #error ac_cv_type_unsigned_long_long=no # So that missing strtoll doesn't #error 1) The wrapper script is silent by default, but I don't think that producing diagnostic output should cause configure to fail... especially since this is only a problem for pcre - all other ebuilds succeed regardless of the verbosity of the wrapper. 2) I've re-jigged the wrapper in order to prepend Portage library paths. I don't think that this should cause a problem, but I'm testing the change to be sure. Unlike with libpcre-7.6 which passes its test-suite cleanly with the above options, libpcre-7.7 fails with: >>> Test phase [check]: dev-libs/libpcre-7.7 make make[1]: Entering directory `/usr/opt/portage/var/tmp/portage/dev-libs/libpcre-7.7/work/pcre-7.7' make all-am make[2]: Entering directory `/usr/opt/portage/var/tmp/portage/dev-libs/libpcre-7.7/work/pcre-7.7' make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/dev-libs/libpcre-7.7/work/pcre-7.7' make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/dev-libs/libpcre-7.7/work/pcre-7.7' make check-TESTS make[1]: Entering directory `/usr/opt/portage/var/tmp/portage/dev-libs/libpcre-7.7/work/pcre-7.7' Testing FullMatch Testing PartialMatch Testing hex Testing octal Testing decimal Testing Replace Testing Extract Testing Consume Testing FindAndConsume Testing QuoteMeta pcrecpp_unittest.cc:475: Check failed: re.FullMatch(unquoted) FAIL: pcrecpp_unittest OK PASS: pcre_scanner_unittest OK PASS: pcre_stringpiece_unittest PCRE C library tests PCRE version 7.6 2008-01-28 Test 1: main functionality (Perl compatible) OK Test 2: API and error handling (not Perl compatible) ./RunTest[143]: 1133638 Memory fault(coredump) FAIL: RunTest Testing pcregrep pcregrep version 7.6 2008-01-28 Testing pcregrep UTF-8 features Testing pcregrep newline settings PASS: RunGrepTest =================== 2 of 5 tests failed =================== make[1]: *** [check-TESTS] Error 1 ... which appears to be a regression from the previous version: with exactly the same environment, libpcre-7.6-r1 succeeds. However, both versions report the same version number and date! Is the libpcre-7.7 test-suite performing tests against the (installed) libpcre-7.6 files?!
Yes, it is! If I merge libpcre-7.7 with FEATURES="-test" then re-merge it with "FEATURES="test" then all tests succeed! This is obviously *totally* broken...
Feels like an "upstream"/gentoo-x86 bug then. I'm working on the rest.
(In reply to comment #3) > Same problem in libpcre-7.7: please could the ebuild be patched to add the > following options for IRIX: > > ac_cv_func_strtoll=no # C99 only > lt_cv_prog_compiler_c_o=yes # See note 1 > lt_cv_prog_compiler_c_o_CXX=yes # See note 1 > ac_cv_type_long_long=no # So that missing strtoll doesn't #error > ac_cv_type_unsigned_long_long=no # So that missing strtoll doesn't #error I added this to the 7.7 ebuild.
looks like we're done here
Has the test-suite issue also been fixed, either here or upstream?
I didn't fix it.
In that case, I'd suggest that - until a better solution be found - the test-suite of this package be masked/disabled even with FEATURES="test".
