Created attachment 313285 [details] dev-libs/openssl-1.0.0j build failure on Gentoo Linux This issue occurs whenever make depend is run with a compiler that is not GCC. I have tried it with both Clang and pathCC. I have verified it with Clang on both Gentoo FreeBSD and Gentoo Linux. This issue appears to affect all architectures. I am filing this to block bug #417789, which is a tracker to enable the BSD team to track the bugs that are blocking Clang 3.1. I am assigning this bug to myself, but honestly, it is the strangest bug I have ever seen. I am CCing basically all parties relevant to it. If you can fix this before I do, by all means, please do.
Created attachment 313487 [details, diff] Patch to fix build failure, assuming ebuild is modified. I have attached a patch that partially fixes this issue. The ebuild has `append-flags $(test-flags-CC -Wa,--noexecstack)`. That causes a build failure with this patch because it is not supported by Clang. Deleting that line from the ebuild makes it work, although that is probably not the right thing to do here. Comments are welcome.
That line in the ebuild could be made the following: expr "$(tc-getCC)" : '.*gcc$' && append-flags $(test-flags-CC -Wa,--noexecstack) Currently, only GCC supports cross compilation, so doing this will prevent Clang from failing while permitting GCC's cross compilation to still work.
At this point, this should be ready for base-system's scrutiny, so I am reassigning the bug to them.
Created attachment 313531 [details, diff] Patch to fix build failure I have trimmed the patch to remove a hunk that was redundant. I have also opened issue #418137 to track the lack of support for -Wa,--noexecstack in Clang.
openssl wants to support a lot of old platforms, so deleting the old depend code won't really work.
(In reply to comment #5) > openssl wants to support a lot of old platforms, so deleting the old depend > code won't really work. The whitespace might be somewhat deceptive here, but what I did was eliminate a conditional by deleting the negative branch. The negative branch was only executed when the compiler was not GCC, but it does not appear to work at all, so deleting it should be okay. Would you elaborate on why deleting it is a problem?
i understand you deleted the old `makedepend` code path. i'm semi-familiar with this having gotten the change merged to recognize any leading path to gcc. my understanding is that older systems want to use `makedepend` when they don't have compilers that can do it. openssl likes to support really old craptastic systems. so i'd like to get feedback on removing support for them first from upstream.
Created attachment 357070 [details, diff] sample patch for openssl-1.0.1e-r1-r1.ebuild I think caused by forced setting to MAKEDEPPROG in ebuild. Changed to set forcibly only when set CC=*gcc. After applying this patch, can be compiled successfully CC=gcc-4.6.4 and CC=clang. Of course, also pass the test phase. @bsd team FreeBSD 9.2-RELEASE coming soon. Please apply this patch if you make the clang stages. FYI, If you want to use ryao's patch (attachment 313531 [details, diff]) continue, please add append-flags $(test-flags-CC -Qunused-arguments) to fix the following problems. >>> Compiling source in /var/tmp/portage/dev-libs/openssl-1.0.1e-r1/work/openssl-1.0.1e-r1 ... gmake -j9 -j1 depend making depend in crypto... gmake[1]: Entering directory `/var/tmp/portage/dev-libs/openssl-1.0.1e-r1/work/openssl-1.0.1e-r1/crypto' clang: error: argument unused during compilation: '-Wa,--noexecstack' gmake[1]: *** [depend] Error 1 gmake[1]: Leaving directory `/var/tmp/portage/dev-libs/openssl-1.0.1e-r1/work/openssl-1.0.1e-r1/crypto' gmake: *** [depend] Error 1
Comment on attachment 357070 [details, diff] sample patch for openssl-1.0.1e-r1-r1.ebuild sorry, but i'm not interested in pulling in makedepend for everyone. clang supports generating makefile dependencies. so figure out how to make the openssl code work using clang.
Still in clang 3.3. /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /var/tmp/portage/dev-libs/openssl-1.0.1f/temp/cryptlib-MyivNZ.o: In function `CRYPTO_get_new_lockid': /var/tmp/portage/dev-libs/openssl-1.0.1f/work/openssl-1.0.1f/crypto/cryptlib.c:213: undefined reference to `sk_new_null' /var/tmp/portage/dev-libs/openssl-1.0.1f/work/openssl-1.0.1f/crypto/cryptlib.c:218: undefined reference to `BUF_strdup' /var/tmp/portage/dev-libs/openssl-1.0.1f/work/openssl-1.0.1f/crypto/cryptlib.c:223: undefined reference to `sk_push' /var/tmp/portage/dev-libs/openssl-1.0.1f/work/openssl-1.0.1f/crypto/cryptlib.c:215: undefined reference to `ERR_put_error'
I've attached a working patch to the gcc bug [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=499818#c1
+ 13 Aug 2014; Michał Górny <mgorny@gentoo.org> openssl-0.9.8z_p2.ebuild, + openssl-1.0.1i.ebuild, openssl-1.0.2_beta2.ebuild: + Short-circuit the $MAKEDEPEND-is-gcc to always-on since we are overriding + MAKEDEPEND unconditionally anyway. Pass -Qunused-arguments when clang is used + to silence the unused flag warnings that can not be fixed without major + changes to the build system, and to make -Werror in "make depend" happier. + Fixes build with CC values that do not end with "gcc", bug #499818, and with + clang, bug #417795. Reviewed by Chainsaw. Just to be clear, openssl-0.9.8z_p2 still fails with clang on an irrelevant issue, but 1.0.1i builds fine.
