There is a new regression in libgcrypt-1.4.4 (as 1.4.3 compiled cleanly, Bug 256111 (which seems to have been fixed) notwithstanding): The MIPSpro compilers use some flags such as '-OPT:value1:value2' - but it seems that a broken 'sed' invocation is replacing *every* instance of "-O" with "-O1" - resulting in this argument being passed as "-O1PT:value1:value2", which causes the compiler to abort. The exact error message is: `echo /opt/portage/bin/bash ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/opt/portage/usr/include -I/opt/portage/usr/include -c99 -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 -woff 1174,1183,1185,1552,3968,3970 -c ./tiger.c | sed -e 's/-O[2-9s]*/-O1/g' ` cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/opt/portage/usr/include -I/opt/portage/usr/include -c99 -O1 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -O1PT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -woff 1174,1183,1185,1552,3968,3970 -c ./tiger.c -DPIC -o .libs/tiger.o cc WARNING: -O1 conflicts with -O; using latter value (-O) cc ERROR parsing -O1PT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON: unknown flag make[2]: *** [tiger.lo] Error 1 make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/dev-libs/libgcrypt-1.4.4/work/libgcrypt-1.4.4/cipher' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/dev-libs/libgcrypt-1.4.4/work/libgcrypt-1.4.4' make: *** [all] Error 2 * ERROR: dev-libs/libgcrypt-1.4.4 failed: * emake failed * * Call stack: * ebuild.sh: 49: <call src_compile> * environment:2139: emake || die "emake failed" ... note the "sed -e 's/-O[2-9s]*/-O1/g'" in there. (And is this reduction in optimisation even valid for anything other than GCC?)
Created attachment 179975 [details, diff] Patch for libgcrypt-1.4.4/cipher/Makefile Patch to try to be a bit more specific with sed recipes...
Actually, this patch is wrong, because make gives special meaning to the two '$'s. They should, of course, be '$$'s. Sorry ;)
I don't want to sound mean or anything, but the prefix team does not have bandwidth to patch up upstream fixes in our tree. a) we are two levels downstream, b) this really, really should be handled directly at upstream's BTS. https://bugs.g10code.com/gnupg/index Please update the URL field with the upstream bug report. Thanks.
Done
ok, added, thanks!
Unfortunately, the patch is being applied *before* configure has generated Makefile, and so is failing :( Either the patch needs to be applied *after* econf is run (which would be in the src_compile stage), or against Makefile.{in|am} instead of Makefile. What's the convention in these cases?
preferably a patch that changes both the am and in, such that a reconf isn't necessary, but when it is run, it doesn't suddenly disappear (like now)
(In reply to comment #7) > preferably a patch that changes both the am and in, In this case, ensure to have the .am _before_ the .in inside the patch to avoid automagic autoreconfs because of timestamp issues.
Created attachment 180704 [details, diff] Patch for libgcrypt-1.4.4/cipher/Makefile.{am|in} Patch, take two. Sorry for the inconvenience.
ok, committed, this should be it then