Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

> On 27 Sep 2019, at 12:50 am, Ken Cunningham  
> wrote:
> 
> If we’re talking about a 2.6.1, please look at incorporating this 10.6.8 fix 
> 

The best way to achieve that I guess would be to open a second PR that cherry 
picks the commit, this time asking to merge to the release-2.6 branch instead 
of master.

Chris

> 
> thanks
> 
> Ken

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Ken Cunningham]

If we’re talking about a 2.6.1, please look at incorporating this 10.6.8 fix 
>

thanks

Ken

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

> On 27 Sep 2019, at 12:39 am, Chris Jones  wrote:
> 
> 
> 
> 
>>> On 27 Sep 2019, at 12:34 am, Ryan Schmidt  wrote:
>>> 
>> 
>> 
>>> On Sep 26, 2019, at 18:28, Riccardo Mottola wrote:
>>> 
>>> Hi,
>>> 
>>> Ryan Schmidt wrote:
> I suppose this is an important fix for 10.5 user, we soon need a 2.6.1
 The list of compiler dependencies is kept in 2 places: in the ports tree, 
 and also in MacPorts base. Chris updated both to fix this issue. The list 
 in MacPorts base only comes into effect if the user doesn't have a ports 
 tree yet, so yes, this change will make it into 2.6.1, but no, there's no 
 urgent need to release 2.6.1 just for this.
>>> 
>>> But first I did a "port selfupdate" and the problem persisted, then I 
>>> patched the file inside port... and it worked. Fromt his I gathered that a 
>>> release is needed...
>> 
>> It takes about an hour for the change to sync from our GitHub repository to 
>> our public rsync server. You presumably selfupdated before the change had 
>> propagated.
> 
> The change in base though really should not be being used I would think. The 
> logic there is only used if the file port1.0/compilers/gcc_dependencies.tcl
> in the ports tree is missing. Surely by now everyone has this, so I would 
> have assumed the logic in base is now really not used (I almost did not 
> bother to make the change there because of this).
> 
> Because of this, its not at all clear to me what hack Riccardo could have 
> done to make things work...

Unless i mis understood what file was hacked, and in fact it was the one in the 
ports tree and not base, as I thought was indicated. That then would make 
sense...

> 
>> 
>> 

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

> On 27 Sep 2019, at 12:34 am, Ryan Schmidt  wrote:
> 
> 
> 
>> On Sep 26, 2019, at 18:28, Riccardo Mottola wrote:
>> 
>> Hi,
>> 
>> Ryan Schmidt wrote:
 I suppose this is an important fix for 10.5 user, we soon need a 2.6.1
>>> The list of compiler dependencies is kept in 2 places: in the ports tree, 
>>> and also in MacPorts base. Chris updated both to fix this issue. The list 
>>> in MacPorts base only comes into effect if the user doesn't have a ports 
>>> tree yet, so yes, this change will make it into 2.6.1, but no, there's no 
>>> urgent need to release 2.6.1 just for this.
>> 
>> But first I did a "port selfupdate" and the problem persisted, then I 
>> patched the file inside port... and it worked. Fromt his I gathered that a 
>> release is needed...
> 
> It takes about an hour for the change to sync from our GitHub repository to 
> our public rsync server. You presumably selfupdated before the change had 
> propagated.

The change in base though really should not be being used I would think. The 
logic there is only used if the file port1.0/compilers/gcc_dependencies.tcl
in the ports tree is missing. Surely by now everyone has this, so I would have 
assumed the logic in base is now really not used (I almost did not bother to 
make the change there because of this).

Because of this, its not at all clear to me what hack Riccardo could have done 
to make things work...

> 
> 

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Ryan Schmidt]

On Sep 26, 2019, at 18:28, Riccardo Mottola wrote:

> Hi,
> 
> Ryan Schmidt wrote:
>>> I suppose this is an important fix for 10.5 user, we soon need a 2.6.1
>> The list of compiler dependencies is kept in 2 places: in the ports tree, 
>> and also in MacPorts base. Chris updated both to fix this issue. The list in 
>> MacPorts base only comes into effect if the user doesn't have a ports tree 
>> yet, so yes, this change will make it into 2.6.1, but no, there's no urgent 
>> need to release 2.6.1 just for this.
> 
> But first I did a "port selfupdate" and the problem persisted, then I patched 
> the file inside port... and it worked. Fromt his I gathered that a release is 
> needed...

It takes about an hour for the change to sync from our GitHub repository to our 
public rsync server. You presumably selfupdated before the change had 
propagated.

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

> On 27 Sep 2019, at 12:29 am, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> Ryan Schmidt wrote:
>>> I suppose this is an important fix for 10.5 user, we soon need a 2.6.1
>> The list of compiler dependencies is kept in 2 places: in the ports tree, 
>> and also in MacPorts base. Chris updated both to fix this issue. The list in 
>> MacPorts base only comes into effect if the user doesn't have a ports tree 
>> yet, so yes, this change will make it into 2.6.1, but no, there's no urgent 
>> need to release 2.6.1 just for this.
> 
> But first I did a "port selfupdate" and the problem persisted, then I patched 
> the file inside port... and it worked. Fromt his I gathered that a release is 
> needed...

Do you have the change in

https://github.com/macports/macports-ports/commit/2e46a05404462e04930b612ed29d9f08ece64603

In the ports tree you are using ?
> 
> 
> Riccardo

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Riccardo Mottola via macports-users]

Hi,

Ryan Schmidt wrote:

I suppose this is an important fix for 10.5 user, we soon need a 2.6.1

The list of compiler dependencies is kept in 2 places: in the ports tree, and 
also in MacPorts base. Chris updated both to fix this issue. The list in 
MacPorts base only comes into effect if the user doesn't have a ports tree yet, 
so yes, this change will make it into 2.6.1, but no, there's no urgent need to 
release 2.6.1 just for this.


But first I did a "port selfupdate" and the problem persisted, then I 
patched the file inside port... and it worked. Fromt his I gathered that 
a release is needed...



Riccardo

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Ryan Schmidt]

On Sep 26, 2019, at 18:12, Riccardo Mottola wrote:

> Chris Jones wrote:
>> https://github.com/macports/macports-ports/commit/2e46a05404462e04930b612ed29d9f08ece64603
>> 
>> I have no way though to test the logic on an OS as ancient as 10.5
> 
> I patched the file locally in my macports then rerun build of harfbuzz 
> and the dependency issue is gone.
> 
> harfbuzz tries to use gcc 6 and a lot of errors ! I forced clang 5.0  and 
> smooth harfbuzz upgraded!

Could you file a bug report about the failures you got using gcc 6, if one 
doesn't already exist?


> I suppose this is an important fix for 10.5 user, we soon need a 2.6.1

The list of compiler dependencies is kept in 2 places: in the ports tree, and 
also in MacPorts base. Chris updated both to fix this issue. The list in 
MacPorts base only comes into effect if the user doesn't have a ports tree yet, 
so yes, this change will make it into 2.6.1, but no, there's no urgent need to 
release 2.6.1 just for this.

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

> On 27 Sep 2019, at 12:13 am, Riccardo Mottola  
> wrote:
> 
> Hi!
> 
> Chris Jones wrote:
>> https://github.com/macports/macports-ports/commit/2e46a05404462e04930b612ed29d9f08ece64603
>> 
>> I have no way though to test the logic on an OS as ancient as 10.5
> 
> I patched the file locally in my macports then rerun build of harfbuzz 
> and the dependency issue is gone.
> 
> harfbuzz tries to use gcc 6 and a lot of errors ! I forced clang 5.0  and 
> smooth harfbuzz upgraded!
> 
> I suppose this is an important fix for 10.5 user, we soon need a 2.6.1

Why ? None of the fixes here require a new release of base

> 
> Riccardo

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Riccardo Mottola via macports-users]

Hi!

Chris Jones wrote:

https://github.com/macports/macports-ports/commit/2e46a05404462e04930b612ed29d9f08ece64603

I have no way though to test the logic on an OS as ancient as 10.5


I patched the file locally in my macports then rerun build of 
harfbuzz and the dependency issue is gone.


harfbuzz tries to use gcc 6 and a lot of errors ! I forced clang 5.0 
 and smooth harfbuzz upgraded!


I suppose this is an important fix for 10.5 user, we soon need a 2.6.1

Riccardo

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

https://github.com/macports/macports-ports/commit/2e46a05404462e04930b612ed29d9f08ece64603

I have no way though to test the logic on an OS as ancient as 10.5

> On 26 Sep 2019, at 10:31 pm, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Hmm, yeah. Now I look at that again its clear the deps are not really right 
> for older systems that do not support all the various gcc versions.
> 
> I think the fix is to not explicitly list all the libgcc versions for each 
> older gcc, but just rely on the fact each libgcc port knows what newer libgcc 
> deps it needs. e.g. libgcc6 knows it needs libgcc7, and so on. so change gcc 
> libgcc7
> 
>  set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc port:libgcc8 
> port:libgcc7 port:libgcc6”
> 
> to just
> 
>  set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc  port:libgcc6"
> 
> so on newer systems, the libgcc6 will also implicitly bring in libgcc7, 
> libgcc8, and libgcc9, but on older systems it will stop on the last supported.
> 
> Chris
> 
>> set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc port:libgcc8 
>> port:libgcc7 port:libgcc6 port:libgcc45"On 26 Sep 2019, at 10:04 pm, Joshua 
>> Root  wrote:
>> 
>>> On 2019-9-27 06:01 , Christopher Jones wrote:
>>> Hi,
>>> 
>>> From the output it appears cmake has a dependency on both libgcc and 
>>> libgcc8. This is not correct on 10.5.
>>> 
>>> You should file a ticket against cmake to bring it to the attention of the 
>>> maintainer.
>> 
>> It's not cmake doing it. The problem is actually this:
>> 
>> 
>> - Josh
> 

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Christopher Jones]

Hi,

Hmm, yeah. Now I look at that again its clear the deps are not really right for 
older systems that do not support all the various gcc versions.

I think the fix is to not explicitly list all the libgcc versions for each 
older gcc, but just rely on the fact each libgcc port knows what newer libgcc 
deps it needs. e.g. libgcc6 knows it needs libgcc7, and so on. so change gcc 
libgcc7

 set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc port:libgcc8 port:libgcc7 
port:libgcc6”

to just

 set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc  port:libgcc6"

so on newer systems, the libgcc6 will also implicitly bring in libgcc7, 
libgcc8, and libgcc9, but on older systems it will stop on the last supported.

Chris

> set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc port:libgcc8 
> port:libgcc7 port:libgcc6 port:libgcc45"On 26 Sep 2019, at 10:04 pm, Joshua 
> Root  wrote:
> 
> On 2019-9-27 06:01 , Christopher Jones wrote:
>> Hi,
>> 
>> From the output it appears cmake has a dependency on both libgcc and 
>> libgcc8. This is not correct on 10.5.
>> 
>> You should file a ticket against cmake to bring it to the attention of the 
>> maintainer.
> 
> It's not cmake doing it. The problem is actually this:
> 
> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Joshua Root]

On 2019-9-27 06:01 , Christopher Jones wrote:
> Hi,
> 
> From the output it appears cmake has a dependency on both libgcc and libgcc8. 
> This is not correct on 10.5.
> 
> You should file a ticket against cmake to bring it to the attention of the 
> maintainer.

It's not cmake doing it. The problem is actually this:


- Josh

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Christopher Jones]

Hi,

From the output it appears cmake has a dependency on both libgcc and libgcc8. 
This is not correct on 10.5.

You should file a ticket against cmake to bring it to the attention of the 
maintainer.

Chris

> On 26 Sep 2019, at 8:54 pm, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> Joshua Root wrote:
>> Actually it looks like that's not the case on Leopard. Could you show
>> the 'port rdeps' output for whatever you're trying to build?
> 
> it shows both versions of libgcc
> I appear to have only one outdated port, harfbuzz, this is the tree:
> 
> 
> The following ports are dependencies of harfbuzz @2.6.1_0:
>   xz
> libiconv
>   gperf
> gettext
>   ncurses
>   pkgconfig
>   gcc6
> cctools
>   libunwind-headers
> gmp
> isl
> ld64
>   ld64-127
> libmacho-headers
> llvm-3.3
>   libffi
>   perl5
> perl5.28
>   db48
>   gdbm
> readline
>   llvm_select
> zlib
> libmpc
>   mpfr
> gcc_select
> libgcc6
>   libgcc7
>   cairo
> libpixman
> glib2
>   autoconf
>   automake
>   libtool
> xattr
>   unzip
>   libxml2
> icu
>   pcre
> bzip2
> libedit
>   python27
> expat
> openssl
> sqlite3
> python_select
> python2_select
> fontconfig
>   freetype
> libpng
>   ossp-uuid
> xrender
>   xorg-libX11
> xorg-xtrans
> xorg-xorgproto
> xorg-util-macros
> clang-8.0
>   cmake
> legacy-support
> curl
>   libidn2
> libunistring
>   texinfo
> help2man
>   p5.28-locale-gettext
>   libpsl
> python37
>   python3_select
>   curl-ca-bundle
> libarchive
>   lzo2
>   lz4
>   zstd
> libuv
> libgcc8
> libgcc
>   clang-5.0
> libomp
> llvm-5.0
>   xar
>   libcxx
> clang_select
>   llvm-8.0
> xorg-libXdmcp
> xorg-libXau
> xorg-libxcb
>   xorg-xcb-proto
>   xorg-libpthread-stubs
> xorg-libXext
> xorg-xcb-util
>   graphite2
> fonttools
>   py37-setuptools
>   py37-brotli
> python36
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Riccardo Mottola via macports-users]

Hi,

Joshua Root wrote:

Actually it looks like that's not the case on Leopard. Could you show
the 'port rdeps' output for whatever you're trying to build?


it shows both versions of libgcc
I appear to have only one outdated port, harfbuzz, this is the tree:


The following ports are dependencies of harfbuzz @2.6.1_0:
  xz
    libiconv
  gperf
    gettext
  ncurses
  pkgconfig
  gcc6
    cctools
  libunwind-headers
    gmp
    isl
    ld64
  ld64-127
    libmacho-headers
    llvm-3.3
  libffi
  perl5
    perl5.28
  db48
  gdbm
    readline
  llvm_select
    zlib
    libmpc
  mpfr
    gcc_select
    libgcc6
  libgcc7
  cairo
    libpixman
    glib2
  autoconf
  automake
  libtool
    xattr
  unzip
  libxml2
    icu
  pcre
    bzip2
    libedit
  python27
    expat
    openssl
    sqlite3
    python_select
    python2_select
    fontconfig
  freetype
    libpng
  ossp-uuid
    xrender
  xorg-libX11
    xorg-xtrans
    xorg-xorgproto
    xorg-util-macros
    clang-8.0
  cmake
    legacy-support
    curl
  libidn2
    libunistring
  texinfo
    help2man
  p5.28-locale-gettext
  libpsl
    python37
  python3_select
  curl-ca-bundle
    libarchive
  lzo2
  lz4
  zstd
    libuv
    libgcc8
    libgcc
  clang-5.0
    libomp
    llvm-5.0
  xar
  libcxx
    clang_select
  llvm-8.0
    xorg-libXdmcp
    xorg-libXau
    xorg-libxcb
  xorg-xcb-proto
  xorg-libpthread-stubs
    xorg-libXext
    xorg-xcb-util
  graphite2
    fonttools
  py37-setuptools
  py37-brotli
    python36

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

what OS is that on ?

yes, on 10.6 and newer I would expect to see that, but on 10.5 it 
shouldn't be the case.


Chris


i.e. see line 43 in

https://github.com/macports/macports-ports/blob/master/lang/gcc7/Portfile

and then line 216.

The depends_run on libgcc8 is only set for Darwin 10 or newer.

Chris

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Joshua Root]

On 2019-9-25 18:31 , Riccardo Mottola wrote:
> Hi,
> 
> Joshua Root wrote:
>> Chris Jones wrote:
>>> Indeed, gcc8 is not supported on 10.5 or older, and likely will never
>>> be.
>>>
>>> What is requiring you to use libgcc8 ?
>> libgcc7, apparently:
>>
>> % port deps libgcc7
>> Full Name: libgcc7 @7.4.0_3
>> Extract Dependencies: xz
>> Build Dependencies:   cctools, gmp, isl, ld64, zlib, libiconv, libmpc,
>> mpfr
>> Library Dependencies:
>> Runtime Dependencies: libgcc8
> 
> that looks somehow... recursive? :)

Actually it looks like that's not the case on Leopard. Could you show
the 'port rdeps' output for whatever you're trying to build?

- Josh

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

On 25/09/2019 7:55 am, Joshua Root wrote:

(forgot to include the list on first sending, apologies for duplicate
message)

Chris Jones wrote:

Indeed, gcc8 is not supported on 10.5 or older, and likely will never be.

What is requiring you to use libgcc8 ?


libgcc7, apparently:

% port deps libgcc7
Full Name: libgcc7 @7.4.0_3
Extract Dependencies: xz
Build Dependencies:   cctools, gmp, isl, ld64, zlib, libiconv, libmpc, mpfr
Library Dependencies:
Runtime Dependencies: libgcc8

- Josh



what OS is that on ?

yes, on 10.6 and newer I would expect to see that, but on 10.5 it 
shouldn't be the case.


Chris

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Joshua Root]

(forgot to include the list on first sending, apologies for duplicate
message)

Chris Jones wrote:
> Indeed, gcc8 is not supported on 10.5 or older, and likely will never be.
> 
> What is requiring you to use libgcc8 ?

libgcc7, apparently:

% port deps libgcc7
Full Name: libgcc7 @7.4.0_3
Extract Dependencies: xz
Build Dependencies:   cctools, gmp, isl, ld64, zlib, libiconv, libmpc, mpfr
Library Dependencies:
Runtime Dependencies: libgcc8

- Josh

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Chris Jones]

Hi,

Indeed, gcc8 is not supported on 10.5 or older, and likely will never be.

What is requiring you to use libgcc8 ? You should instead be using libgcc7 on 
that platform. Note this is what the libgcc port is there for, to set up this 
dependency correctly.

https://github.com/macports/macports-ports/blob/master/lang/libgcc/Portfile

Chris

> On 24 Sep 2019, at 11:40 pm, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi,
> 
> I don't know if it is related to the 2.6 upgrade or it is "just" an upgrade, 
> but on Leopard 10.5, I get the following:
> 
> --->  Cleaning curl
> --->  Removing work directory for curl
> --->  Computing dependencies for libgcc8.
> --->  Fetching archive for libgcc8
> --->  libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 doesn't seem to exist in 
> /opt/local/var/macports/incoming/verified
> --->  Attempting to fetch libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 from 
> http://lil.fr.packages.macports.org/libgcc8
> 
>  % Total% Received % Xferd  Average Speed   TimeTime Time Current
> Dload  Upload   Total   SpentLeft Speed
>  0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 from 
> http://nue.de.packages.macports.org/libgcc8
> 
>  % Total% Received % Xferd  Average Speed   TimeTime Time Current
> Dload  Upload   Total   SpentLeft Speed
>  0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 from 
> http://fco.it.packages.macports.org/mirrors/macports-packages/libgcc8
> 
>  % Total% Received % Xferd  Average Speed   TimeTime Time Current
> Dload  Upload   Total   SpentLeft Speed
>  0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Fetching distfiles for libgcc8
> Error: gcc8 8.3.0 is not supported on Darwin 9
> Error: Failed to fetch libgcc8: incompatible OS X version
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/main.log
>  for details.
> Error: Problem while installing libgcc8
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> 
> now... it means I can't have (yet) gcc8...
> Maybe we can make the dependency of libgcc less stringgend... or Ken is 
> already doing some magic for gcc 8 support?
> 
> In my experience, gcc 8 is an evolution of gcc6 which is a "good" compiler, 
> but gcc8 broke quite some things (like... ArcticFox compilation)
> 
> Riccardo

MacPorts 2.6 - Leopard 20.6 and libgcc8

[Riccardo Mottola via macports-users]

Hi,

I don't know if it is related to the 2.6 upgrade or it is "just" an 
upgrade, but on Leopard 10.5, I get the following:


--->  Cleaning curl
--->  Removing work directory for curl
--->  Computing dependencies for libgcc8.
--->  Fetching archive for libgcc8
--->  libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 doesn't seem to exist in 
/opt/local/var/macports/incoming/verified
--->  Attempting to fetch libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 from 
http://lil.fr.packages.macports.org/libgcc8


  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
  0 00 00 0  0  0 --:--:--  0:00:04 
--:--:-- 0--->  Attempting to fetch 
libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 from 
http://nue.de.packages.macports.org/libgcc8


  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
  0 00 00 0  0  0 --:--:--  0:00:04 
--:--:-- 0--->  Attempting to fetch 
libgcc8-8.3.0_5.darwin_9.x86_64.tbz2 from 
http://fco.it.packages.macports.org/mirrors/macports-packages/libgcc8


  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
  0 00 00 0  0  0 --:--:--  0:00:04 
--:--:-- 0--->  Fetching distfiles for libgcc8

Error: gcc8 8.3.0 is not supported on Darwin 9
Error: Failed to fetch libgcc8: incompatible OS X version
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/main.log 
for details.

Error: Problem while installing libgcc8
Error: Follow https://guide.macports.org/#project.tickets to report a bug.


now... it means I can't have (yet) gcc8...
Maybe we can make the dependency of libgcc less stringgend... or Ken is 
already doing some magic for gcc 8 support?


In my experience, gcc 8 is an evolution of gcc6 which is a "good" 
compiler, but gcc8 broke quite some things (like... ArcticFox compilation)


Riccardo