Bug 231804 - lang/gcc7: fix build with powerpc64
Summary: lang/gcc7: fix build with powerpc64
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Andreas Tobler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-29 18:24 UTC by Piotr Kubaj
Modified: 2018-12-11 21:02 UTC (History)
6 users (show)

See Also:
gerald: maintainer-feedback+


Attachments
patch (1.22 KB, patch)
2018-09-29 18:24 UTC, Piotr Kubaj
no flags Details | Diff
log with breakage (246.73 KB, application/x-xz)
2018-09-29 18:26 UTC, Piotr Kubaj
no flags Details
patch lang/gcc7 to disable multilib on ppc64 by default (423 bytes, patch)
2018-11-24 19:06 UTC, Steve Wills
no flags Details | Diff
gcc no rpath patch from Andreas T (1.61 KB, patch)
2018-11-28 15:57 UTC, Steve Wills
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kubaj 2018-09-29 18:24:37 UTC
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.
Comment 1 Piotr Kubaj 2018-09-29 18:26:06 UTC
Created attachment 197602 [details]
log with breakage
Comment 2 Gerald Pfeifer freebsd_committer 2018-09-29 18:46:48 UTC
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?
Comment 3 Piotr Kubaj 2018-09-29 19:00:09 UTC
(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.
Comment 4 Gerald Pfeifer freebsd_committer 2018-09-29 19:10:26 UTC
(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.
Comment 5 Andreas Tobler freebsd_committer 2018-09-29 20:33:21 UTC
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.
Comment 6 Piotr Kubaj 2018-09-29 20:36:02 UTC
(In reply to Andreas Tobler from comment #5)
Thanks. Any idea why it didn't happen with ALPHA5?
Comment 7 Andreas Tobler freebsd_committer 2018-09-29 20:50:56 UTC
No, not yet. It should have come up long ago.
Comment 8 Piotr Kubaj 2018-09-29 21:03:15 UTC
(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?
Comment 9 Gerald Pfeifer freebsd_committer 2018-10-02 22:56:29 UTC
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)?
Comment 10 Andreas Tobler freebsd_committer 2018-10-03 18:17:36 UTC
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...
Comment 11 commit-hook freebsd_committer 2018-10-04 07:08:50 UTC
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
Comment 12 commit-hook freebsd_committer 2018-10-06 18:00:57 UTC
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
Comment 13 commit-hook freebsd_committer 2018-10-07 06:09:45 UTC
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
Comment 14 commit-hook freebsd_committer 2018-10-16 15:23:54 UTC
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
Comment 15 Piotr Kubaj 2018-10-16 15:38:52 UTC
(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)      |                          ^~
Comment 16 Gerald Pfeifer freebsd_committer 2018-10-16 15:40:55 UTC
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.
Comment 17 commit-hook freebsd_committer 2018-10-20 10:59:24 UTC
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
Comment 18 Sean Bruno freebsd_committer 2018-11-22 16:00:28 UTC
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".
Comment 19 Steve Wills freebsd_committer 2018-11-24 19:06:56 UTC
Created attachment 199519 [details]
patch lang/gcc7 to disable multilib on ppc64 by default

I've confirmed the attached patch fixes it. Any objection?
Comment 20 Gerald Pfeifer freebsd_committer 2018-11-25 15:12:49 UTC
(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?
Comment 21 Steve Wills freebsd_committer 2018-11-28 15:56:12 UTC
(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.
Comment 22 Steve Wills freebsd_committer 2018-11-28 15:57:26 UTC
Created attachment 199641 [details]
gcc no rpath patch from Andreas T

Here's the patch mentioned in my previous comment.
Comment 23 Steve Wills freebsd_committer 2018-11-28 21:26:50 UTC
(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?
Comment 24 Steve Wills freebsd_committer 2018-11-28 21:40:36 UTC
(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
Comment 25 Steve Wills freebsd_committer 2018-11-28 21:47:39 UTC
(In reply to Steve Wills from comment #24)
Ignore that, the host where I tested lacks /usr/lib32
Comment 26 Steve Wills freebsd_committer 2018-11-28 21:53:56 UTC
(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!
Comment 27 commit-hook freebsd_committer 2018-11-29 16:16:32 UTC
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
Comment 28 Steve Wills freebsd_committer 2018-12-05 00:10:05 UTC
Ok to commit the patch from Andreas?
Comment 29 Gerald Pfeifer freebsd_committer 2018-12-11 16:12:35 UTC
(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.
Comment 30 Andreas Tobler freebsd_committer 2018-12-11 21:02:32 UTC
Thanks for the feedback Gerald!
Testing the patch on all active gcc ports. Will then commit.