Created attachment 197601 [details] patch After upgrade from 12.0-ALPHA5 to 12.0-ALPHA8 I can't compile gcc7 anymore (attaching log from Poudriere). I made this quick patch to fix compilation, it works. I'm not sure whether it affects also sparc64. Hardware sponsored by IntegriCloud.
Created attachment 197602 [details] log with breakage
Thank you, but...something's really odd here. This includes *two* distinct changes which appear quite unrelated and completely unrelated to powerpc64. So, if anything, this may be related to FreeBSD as such, but this is the first and only report in that direction ever. Can you also reproduce this on x86-64 (aka amd64 in FreeBSD land)? Do you have any special settings somewhere? CFLAGS_powerpc64=-DHAVE_WORKING_STAT looks very bogus to me in several ways (powerpc64 only, and why it should be necessary to begin with). The code in question related to the other issue appears to be #if !HAVE_UNLINK_OPEN_FILE path = strdup (u->filename); #endif Now it might be that this path is hardly executed usually, and that your proposed change makes sense. However: why did nobody else on any platform run into this for months, if not years? This code was introduced upstream in 2014-09-16, more than four years ago. I will see what I can do around that, but either FreeBSD late in the 12.0 release cycle and/or you may have made some interesting/unusual decisions somewhere?
(In reply to Gerald Pfeifer from comment #2) I know it's strange, that's why I posted this log :) I have no modifications, only vanilla FreeBSD/powerpc64 12.0-ALPHA8, my make.conf is exactly this: DEVELOPER=yes WRKDIRPREFIX=/tmp I have the same error with gcc6 and will post a patch later. For now, I'll try poudriere testport on amd64.
(In reply to Piotr Kubaj from comment #3) > I have the same error with gcc6 and will post a patch later. Lets focus on current versions of GCC. GCC 7 is the default for FreeBSD right now, GCC 8 available in its second release, and GCC 9 under development. The second issue I will address upstream *but* please try to find out why nobody else ran into this (which probably means this code path did not trigger). The first one is the truly odd one.
This is a known issue. You build a 64-bit gcc with multilib support. Now while configuring for the 32-bit libgfortran we pull in the wrong set of libraries, which are not 32-bit. Then we fail to provide the function configure is looking for. The issue is this, our port mechanics sets a rpath which points to the hosting gcc and we use these libraries if we configure the newly built gcc's libraries. If the above would be solved, there is a second issue, we do not install 32-bit libraries yet. If you do not need multilibs, disable them and you should be able to build a gcc for your platform. I have a set of patches to solve both issues. In short, you do not need to patch gcc, it is a port issue.
(In reply to Andreas Tobler from comment #5) Thanks. Any idea why it didn't happen with ALPHA5?
No, not yet. It should have come up long ago.
(In reply to Andreas Tobler from comment #7) Ok, then. In that case, could you disable MULTILIB for powerpc64, so that the package builds without changing options?
As I observed, there are two distinct issues reported/fixed, and while Andreas indicated he'll work on the bigger one (thank you!) there *is* a bug in GCC that I just fixed upstream, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html This is going to be in the next update for gcc9-devel and I plan on pushing it back to the upstream GCC 8, GCC 7 and GCC 6 branches, so it'll first hit gcc8-devel, then gcc7-devel, and later gcc6-devel and then the gcc8, gcc7, and gcc6 ports (either when there are new upstream releases or if I push a FreeBSD local patch for the time being). Andreas, any indication whether your fixes are going to make mine obsolete (though still correct, just not applicable on FreeBSD then)?
Don't know yet. But it'll take a few weeks until I have the patches tested. My main tester is out of work since a month. And bisecting is a painful job...
A commit references this bug: Author: gerald Date: Thu Oct 4 07:07:56 UTC 2018 New revision: 481205 URL: https://svnweb.freebsd.org/changeset/ports/481205 Log: Update to the 20180930 snapshot of GCC 9. This contains a partial fix in the context of PR 231804 that I made upstream, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html . PR: 231804 Changes: head/lang/gcc9-devel/Makefile head/lang/gcc9-devel/distinfo
A commit references this bug: Author: gerald Date: Sat Oct 6 18:00:46 UTC 2018 New revision: 481382 URL: https://svnweb.freebsd.org/changeset/ports/481382 Log: Update to the 20181005 snapshot of GCC 8.2.1. This brings a partial fix for what was reported in PR 231804 that I made upstream, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html . PR: 231804 Changes: head/lang/gcc8-devel/Makefile head/lang/gcc8-devel/distinfo
A commit references this bug: Author: gerald Date: Sun Oct 7 06:08:45 UTC 2018 New revision: 481429 URL: https://svnweb.freebsd.org/changeset/ports/481429 Log: Update to the 20181004 snapshot of GCC 7.3.1. Add a partial fix for what was reported in PR 231804, the part that's actually relevant upstream and that I made there, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html as a new local patch files/patch-libgfortran until I have backported this to the upstream release branch and hence we get it via the weekly snapshots. PR: 231804 Changes: head/lang/gcc7-devel/Makefile head/lang/gcc7-devel/distinfo head/lang/gcc7-devel/files/patch-libgfortran
A commit references this bug: Author: gerald Date: Tue Oct 16 15:23:41 UTC 2018 New revision: 482234 URL: https://svnweb.freebsd.org/changeset/ports/482234 Log: Update to the 20181003 snapshot of GCC 6.4.1. Add a partial fix for what was reported in PR 231804, specifically the part that's actually relevant upstream and that I made there, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html as a new local patch files/patch-libgfortran until I have backported this to the upstream release branch and hence we get it via the weekly snapshots. PR: 231804 Changes: head/lang/gcc6-devel/Makefile head/lang/gcc6-devel/distinfo head/lang/gcc6-devel/files/patch-libgfortran
(In reply to commit-hook from comment #14) Just to be sure you know, building gcc9-devel still fails: (09:26:56) /wrkdirs/usr/ports/lang/gcc9-devel/work/gcc-9-20181007/libgfortran/io/unix.c: In function 'find_file': (09:26:56) /wrkdirs/usr/ports/lang/gcc9-devel/work/gcc-9-20181007/libgfortran/io/unix.c:1682:26: error: 'id' undeclared (first use in this function) (09:26:56) 1682 | # define FIND_FILE0_ARGS id, path (09:26:56) | ^~ (09:26:56) /wrkdirs/usr/ports/lang/gcc9-devel/work/gcc-9-20181007/libgfortran/io/unix.c:1756:30: note: in expansion of macro 'FIND_FILE0_ARGS' (09:26:56) 1756 | u = find_file0 (unit_root, FIND_FILE0_ARGS); (09:26:56) | ^~~~~~~~~~~~~~~ (09:26:56) /wrkdirs/usr/ports/lang/gcc9-devel/work/gcc-9-20181007/libgfortran/io/unix.c:1682:26: note: each undeclared identifier is reported only on ce for each function it appears in (09:26:56) 1682 | # define FIND_FILE0_ARGS id, path (09:26:56) | ^~
Hi everyone, just to provide a summary of my recent changes: The lang/gcc[6789]-devel ports have received fixes for one of the two issues (so only one of the two workarounds should still be necessary) and I've updated the respective release branches upstream, so local patches have been becoming obsolete as we update to those newer snapshots. The lang/gcc[678] ports will receive those updates with their next releases.
A commit references this bug: Author: gerald Date: Sat Oct 20 10:59:10 UTC 2018 New revision: 482485 URL: https://svnweb.freebsd.org/changeset/ports/482485 Log: Copy over files/patch-libgfortran from revision r481429 of lang/gcc7-devel: Add a partial fix for what was reported in PR 231804, the part that's actually relevant upstream and that I made there, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html as a new local patch files/patch-libgfortran until I have backported this to the upstream release branch and hence we get it via the weekly snapshots. PR: 231804 Changes: head/lang/gcc7/files/patch-libgfortran
http://pylon.nyi.freebsd.org/build.html?mastername=head-powerpc64-default&build=p485579_s340750 It appears that the current state of gcc7 in ports is still "not quite right".
Created attachment 199519 [details] patch lang/gcc7 to disable multilib on ppc64 by default I've confirmed the attached patch fixes it. Any objection?
(In reply to Steve Wills from comment #19) > I've confirmed the attached patch fixes it. Any objection? I'd say it works around it? No objection from my side, but Andreas T. really is the expert here who put support for powerpc64 and this snippet in place, so let's give him a couple of days to comment?
(In reply to Gerald Pfeifer from comment #20) You're right, I meant to say it that way, sorry. I had already mailed Andreas and he mailed me a patch which I'm testing now.
Created attachment 199641 [details] gcc no rpath patch from Andreas T Here's the patch mentioned in my previous comment.
(In reply to Steve Wills from comment #22) This builds OK for me on amd64 and on ppc64 and Andreas has been using it for a while without issue. Look good?
(In reply to Steve Wills from comment #23) But my runtime testing failed: % gcc7 -m32 -o hello hello.c /usr/local/bin/ld: skipping incompatible /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd13.0/7.3.0/../../../libgcc_s.so when searching for -lgcc_s /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc_s.so when searching for -lgcc_s /usr/local/bin/ld: cannot find -lgcc_s /usr/local/bin/ld: skipping incompatible /lib/libc.so.7 when searching for /lib/libc.so.7 /usr/local/bin/ld: cannot find /lib/libc.so.7 /usr/local/bin/ld: skipping incompatible /usr/lib/libc_nonshared.a when searching for /usr/lib/libc_nonshared.a /usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a /usr/local/bin/ld: skipping incompatible /usr/lib/libssp_nonshared.a when searching for /usr/lib/libssp_nonshared.a /usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a collect2: error: ld returned 1 exit status
(In reply to Steve Wills from comment #24) Ignore that, the host where I tested lacks /usr/lib32
(In reply to Steve Wills from comment #25) It seems that on a host with /usr/lib32, gcc7 built with this patch produces 32bit binaries that run: # gcc7 -o hello -m32 hello.c # file hello hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 13.0 (1300004), with debug_info, not stripped # ./hello hello, world # At least with trivial code, it works!
A commit references this bug: Author: antoine Date: Thu Nov 29 16:15:29 UTC 2018 New revision: 486177 URL: https://svnweb.freebsd.org/changeset/ports/486177 Log: MFH: r482485 Copy over files/patch-libgfortran from revision r481429 of lang/gcc7-devel: Add a partial fix for what was reported in PR 231804, the part that's actually relevant upstream and that I made there, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html as a new local patch files/patch-libgfortran until I have backported this to the upstream release branch and hence we get it via the weekly snapshots. PR: 231804 Changes: _U branches/2018Q4/ branches/2018Q4/lang/gcc7/files/patch-libgfortran
Ok to commit the patch from Andreas?
(In reply to Steve Wills from comment #28) > Ok to commit the patch from Andreas? Yes, only some minor things, two related questions, and one general ask: - "...while building gcc itself..." -> "...GCC..." (all uppercase) - Why TARGLIB= ${PREFIX}/lib/gcc${SUFFIX} but TARG32LIB=${PREFIX}/lib32 ? That is, why is there nothing GCC version-specific in TARG32LIB? In turn you copy things over later in the game. That may be necessary, but warrants a comment. - Could we make this TARGLIB32, or do you folks strongly prefer TARG32LIB? - Where it currently has ${MKDIR} -p ${STAGEDIR}${PREFIX}/lib32/gcc${SUFFIX} that definitely should be using ${TARG32LIB} (or ${TARGLIB32} in case)! Same for the line below and in general, please. With the above considered, Approved by: gerald (maintainer) Steve, Andreas and me had a brief e-mail exchange, and I believe he's going to commit himself like he's done in other instances.
Thanks for the feedback Gerald! Testing the patch on all active gcc ports. Will then commit.
A commit references this bug: Author: andreast Date: Sat Dec 29 15:38:31 UTC 2018 New revision: 488673 URL: https://svnweb.freebsd.org/changeset/ports/488673 Log: Fix build of GCC on powerpc64. While building GCC itself we have to use the built GCC libraries to configure additional parts of GCC and not the libraires from the host. Install the built 32-bit libraries. This was not done up to now. PR: 231804 Approved by: gerald@ Changes: head/Mk/bsd.gcc.mk head/lang/gcc7/Makefile
I guess I can close this one, right?
A commit references this bug: Author: gerald Date: Fri Mar 1 01:11:01 UTC 2019 New revision: 494220 URL: https://svnweb.freebsd.org/changeset/ports/494220 Log: Backport r488673 | andreast | 2018-12-29 from lang/gcc7: Fix build of GCC on powerpc64. While building GCC itself we have to use the built GCC libraries to configure additional parts of GCC and not the libraires from the host. Install the built 32-bit libraries. This was not done up to now. And no longer required GCC 5 to build on powerpc64, making this port a natural choice of a "base" for newer members of the lang/gcc* family. PR: 235964, 231804 Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> Changes: head/lang/gcc6/Makefile
A commit references this bug: Author: gerald Date: Sat Mar 2 18:05:04 UTC 2019 New revision: 494448 URL: https://svnweb.freebsd.org/changeset/ports/494448 Log: Update to the 20190228 snapshot of GCC 7.4.1. Simplify the creation of the multilib-related tree on powerpc64 and avoid leaving an empty directory behind on the way. [1] PR: 235964, 231804 [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [1] Changes: head/lang/gcc7-devel/Makefile head/lang/gcc7-devel/distinfo
A commit references this bug: Author: gerald Date: Mon Mar 4 03:01:59 UTC 2019 New revision: 494541 URL: https://svnweb.freebsd.org/changeset/ports/494541 Log: Update to the 20180301 snapshot of GCC 8.3.1. Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. [1] Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there. PR: 235964, 231804 [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [1] Changes: head/lang/gcc8-devel/Makefile head/lang/gcc8-devel/distinfo
A commit references this bug: Author: gerald Date: Wed Mar 6 11:21:15 UTC 2019 New revision: 494789 URL: https://svnweb.freebsd.org/changeset/ports/494789 Log: Update to the 20180303 snapshot of GCC 9.0.1. Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. [1] Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there. PR: 235964, 231804 [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [1] Changes: head/lang/gcc9-devel/Makefile head/lang/gcc9-devel/distinfo head/lang/gcc9-devel/pkg-descr
A commit references this bug: Author: gerald Date: Thu Mar 7 09:55:53 UTC 2019 New revision: 494921 URL: https://svnweb.freebsd.org/changeset/ports/494921 Log: No longer require a not too old version of GCC to build on powerpc64, but rely on the system compiler (even if that means we need to be explicitly conservative when it comes to optimizations). [1] Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. [2] Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there. PR: 235975 [1], 235964 [2], 231804 [2] Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [2] Changes: head/lang/gcc8/Makefile head/lang/gcc8/pkg-descr
A commit references this bug: Author: gerald Date: Sun Mar 10 05:22:49 UTC 2019 New revision: 495227 URL: https://svnweb.freebsd.org/changeset/ports/495227 Log: No longer require a not too old version of GCC to build on powerpc64, but rely on the system compiler (even if that means we need to be explicitly conservative when it comes to optimizations). [1] Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. [2] PR: 235975 [1], 235964 [2], 231804 [2] Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [2] Changes: head/lang/gcc7/Makefile
A commit references this bug: Author: gerald Date: Tue Mar 12 15:56:13 UTC 2019 New revision: 495463 URL: https://svnweb.freebsd.org/changeset/ports/495463 Log: Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. PR: 235964, 231804 Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> Changes: head/lang/gcc6/Makefile