pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gcc on Darwin


On 12/4/20 5:45 PM, Jason Bacon wrote:


On 10/13/20 7:01 PM, Jason Bacon wrote:

On 10/13/20 4:28 PM, Jonathan Perkin wrote:

* On 2020-10-13 at 21:47 BST, Jason Bacon wrote:
Anyone else having trouble with gcc7 and gcc8 on Darwin lately? I haven't tried other gcc versions yet.  This is on High Sierra, since my newest Mac is 10 years old.  If the gcc packages are working on more recent OS X, I wouldn't make fixing this a high priority, since support for High Sierra 
will likely end soon.
They all build fine and are available for my current Mojave package sets: 

   $ pkgin se ^gcc[0-9]*-[0-9]
   gcc10-10.2.0nb1      The GNU Compiler Collection (GCC) - 10.0 Release Series    gcc7-7.5.0nb3        The GNU Compiler Collection (GCC) - 7.0 Release Series    gcc8-8.4.0nb2        The GNU Compiler Collection (GCC) - 8.0 Release Series 

They also built fine on my recent Big Sur bulk build, though gcc10 did
run into a space problem in /var/tmp that I'll look into fixing.

Also for my historical Sierra sets they're all available, though are
slightly older than what's in pkgsrc right now, but if you just need
to get things running then you may find them useful:
   $ export PKG_REPOS=https://us-east.manta.joyent.com/pkgsrc/public/packages/Darwin/10.12/trunk/x86_64/All 
   $ pkgin se ^gcc[0-9]*-[0-9]
   gcc48-4.8.5nb8       The GNU Compiler Collection (GCC) - 4.8 Release Series    gcc5-5.5.0nb5        The GNU Compiler Collection (GCC) - 5 Release Series    gcc6-6.5.0nb3        The GNU Compiler Collection (GCC) - 6 Release Series    gcc7-7.4.0nb3        The GNU Compiler Collection (GCC) - 7.0 Release Series    gcc8-8.3.0nb1        The GNU Compiler Collection (GCC) - 8.0 Release Series 

Doesn't directly address the issue you're running into but hopefully
at least provides some data points to help pinpoint any causes.
Thanks for the detailed data.  They were both working fine for me on High Sierra some months ago.  I ran into this while running pkg_chk -u today after a cvs update.
I'll look into when I can make some time to see if there's an easy fix, but it's time for some newer hardware, much as I hate to admit it.
From a quick closer look, it seems that configure is not generating the right include path.
I'm assuming the gcc packages should be using their own bundled libunwind: 

find work -name unwind.h
work/build/gcc/include/unwind.h
work/build/x86_64-apple-darwin17/libgcc/unwind.h
But the failing compile command isn't using either of these headers, and it's finding /usr/include/unwind.h instead, which I'm guessing is incompatible:
Darwin marlin.acadix  bacon ~/Pkgsrc/pkgsrc/lang/gcc7 1065: (pkgsrc): cat compile-cmd /Users/bacon/Pkgsrc/pkgsrc/lang/gcc7/work/build/./gcc/xgcc -B/Users/bacon/Pkgsrc/pkgsrc/lang/gcc7/work/build/./gcc/ -B/Users/bacon/Pkgsrc/pkg/gcc7/x86_64-apple-darwin17/bin/ -B/Users/bacon/Pkgsrc/pkg/gcc7/x86_64-apple-darwin17/lib/ -isystem /Users/bacon/Pkgsrc/pkg/gcc7/x86_64-apple-darwin17/include -isystem /Users/bacon/Pkgsrc/pkg/gcc7/x86_64-apple-darwin17/sys-include -g -O2 -I/Users/bacon/Pkgsrc/pkg/include -I/usr/include -O2 -g -O2 -I/Users/bacon/Pkgsrc/pkg/include -I/usr/include -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include  -I. -I. -I../.././gcc -I../../../gcc-7.5.0/libgcc -I../../../gcc-7.5.0/libgcc/. -I../../../gcc-7.5.0/libgcc/../gcc -I../../../gcc-7.5.0/libgcc/../include   -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc -I../../../gcc-7.5.0/libgcc -I../../../gcc-7.5.0/libgcc/. -I../../../gcc-7.5.0/libgcc/../gcc -I../../../gcc-7.5.0/libgcc/../include  -o crttme.o -MT crttme.o -MD -MP -MF crttme.dep -mmacosx-version-min=10.4 -DEND -c ../../../gcc-7.5.0/libgcc/config/darwin-crt-tm.c In file included from ../../../gcc-7.5.0/libgcc/config/unwind-dw2-fde-darwin.c:31:0: /usr/include/unwind.h:208:48: warning: 'unavailable' attribute directive ignored [-Wattributes]  extern uintptr_t _Unwind_GetDataRelBase(struct _Unwind_Context* context) __attribute__((unavailable));
I'm not sure of the best way to get the include directories above into the path before /usr/include.  It's a complex build system I'm not too familiar with.
I also wonder whether it's using the bundled libunwind on newer versions of Darwin, or whether the system unwind.h is just newer and works with the gcc packages. 

Any suggestions appreciated.

    JB


I confirmed what the problem is by hacking around it:

cp work/build/gcc/include/unwind.h ${PREFIX}/include
${PREFIX}/include is the only directory preceding /usr/include that actually exists.  Simply copying gcc's bundled unwind.h there allowed the build to complete successfully.
It appears that the gcc build system is intending to use its own libundinw, but simply not generating the right include path to protect itself from leakage of the system unwind into the build. Use of system libunwind is off by default and enabled with --with-system-libundind in the libgcc configure script.
I haven't figured out a clean way to correct this issue yet, so I'm just posting the workaround for now. 

    JB
Home | Main Index | Thread Index | Old Index