Differential D10357
lang/gcc fix build with poudriere bulk -t /testport Authored by miwi on Apr 11 2017, 9:42 AM. Tags None Referenced Files
Subscribers
Details
The new qa script is a little bit more strict, so currently the build fails [1] when we run poudriere testport / bulk -t, [1]
Diff Detail
Event TimelineComment Actions First of all, thanks for doing this, Martin! This is generally fine for lang/gcc, but also lang/gcc5, lang/gcc5-devel, Out of curiosity: Did you focus on lang/gcc since it's the most widely (I wrote "generally fine" since I've got a question/small ask or two.)
Yes, but... I tried exactly this in January 2015 and ran into problems, (This was still on my todo list, actually. :-/) Do you have an idea why the very same thing I did two years ago now Mind moving this line directly below the ALL_TARGET a bit lower in
The qa script is now going to catch this? Cool. Note, there is a .if ${PORT_OPTIONS:MJAVA} block a bit down in Thanks, and Approved by: gerald (maintainer) [ideally with the two Gerald Comment Actions Bad news. I just gave the patch with the INSTALL_TARGET change a test -z 'strip' || strip /scratch/tmp/gerald/gcc7-devel-work/stage/scratch/tmp/gerald/gcc7-devel-prefix/libexec/gcc7/gcc/i386-portbld-freebsd10.3/7.0.1/install-tools/fixincl
This is on ref10-i386.freebsd.org building as a regular user. Comment Actions My focus was only on lang/gcc, I hit it while testing other ports ;).
Not entirely sure, but a lot things have change over the last few years.
ups I missed that part, I will update the patch in few mins.
done.
Comment Actions
lang/gcc: lang/gcc5: lang/gcc5-devel lang/gcc6/ lang/gcc6-devel lang/gcc7-devel Comment Actions A few updates from my side:
Comment Actions The shebangfix changes being committed earlier now are triggering WARN: Makefile: [48]: possible direct use of command "python" found.
use ${PYTHON_CMD} instead.I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218672 for Comment Actions Attached a little reproducer on how to build lang/gcc7-devel with Comment Actions I looked into this a bit more: The invocation that aborts the build is test -z 'strip' || strip /scratch/tmp/gerald/work/stage/scratch/tmp/gerald/prefix/libexec/gcc7/gcc/i386-portbld-freebsd10.3/7.0.1/install-tools/fixincl strip: unable to copy file '/scratch/tmp/gerald/work/stage/scratch/tmp/gerald/prefix/libexec/gcc7/gcc/i386-portbld-freebsd10.3/7.0.1/install-tools/fixincl'; reason: Permission denied gmake[3]: *** [Makefile:191: install-strip] Error 1 The file in question does exist, and file reports ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.3 (1003508), FreeBSD-style, stripped The permissions of the file are -r-xr-xr-x. Comment Actions Digging into this some more I tested two potential workaround for the permission problem that Tijl suggested when I first looked into this myself two years ago. Setting BINMODE=755 and setting STRIP=true in CONFIGURE_ARGS. Both allow the build to succeed as a regular user (non-root), when INSTALL_TARGET=install-strip is set, but with the latter there are many files left that end up being not stripped, whereas with the BINMODE setting the list is down to one file. This appears to be the case since various aspects of GCC do not use our install-* tools, but a script install-sh (which you can find at the root of the GCC source tree that uses cp, chmod, strip,... for compatibility reasons with many systems). Comment Actions This is how a working patch looks like (with BINMODE setting in Are we okay with that? Comment Actions Somehow Phabricator doesn't like me today, but in any case, here is what seems to do the job, I plan on applying this to lang/gcc6, lang/gcc7 and lang/gcc5 (in that order) unless there are Index: Makefile
+++ Makefile (working copy) --enable-gnu-indirect-function \
--libdir=${TARGLIB} \Comment Actions The shebang fixes have been addressed this spring for all my lang/gcc* ports, now the stripping |