Re: Is it possible to influence at what UID MacPorts start to create users?

[Gerben Wierda]

If this is a bug, I suggest using 600, not 500 for the fix.100 local users on a 
mac seems adequate (like 640kB…) and server starts at 1025, so ample room for 
services.

I’d rather not create my own macports port, it is complex enough as it is.

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

> On 14 Aug 2019, at 23:55, Ryan Schmidt  wrote:
> 
> 
> 
> On Aug 14, 2019, at 16:36, Gerben Wierda wrote:
> 
>> If you create local userson macOS, it starts with uid 501 and then goes up. 
>> (for network users it always (still?) started with 1025 and then goes up.
>> 
>> MacPorts, when it creates users, starts with 500 and then goes up.
> 
> I noticed that too... I think this is a bug. I think we meant to start user 
> IDs at 501, just like Apple. In ./src/pextlib1.0/Pextlib.c the comment 
> describing the function NextuidCmd says it will "Find the first unused UID > 
> 500" but it actually starts at the value of MIN_USABLE_UID which the 
> configure script hardcodes as 500.
> 
> 
>> So, depending on the order of creation, the same user has different uid 
>> (same for groups). It is not generally a problem, but I don’t like it. 
>> Depending on the order of actions on a system you get different uids for 
>> different MacPorts-generated users, intermingled with created local users.
>> 
>> I’d like to tell macports to start at another number, to lessen the chance 
>> of this.
> 
> There isn't a setting for the user to change this. If you want to change it, 
> you'll have to edit the number in the MacPorts base configure script, 
> reconfigure, and recompile.
> 
> Just make sure you don't use UIDs less than 500, which are reserved.
> 

Re: Is it possible to influence at what UID MacPorts start to create users?

[Ryan Schmidt]

On Aug 14, 2019, at 16:36, Gerben Wierda wrote:

> If you create local userson macOS, it starts with uid 501 and then goes up. 
> (for network users it always (still?) started with 1025 and then goes up.
> 
> MacPorts, when it creates users, starts with 500 and then goes up.

I noticed that too... I think this is a bug. I think we meant to start user IDs 
at 501, just like Apple. In ./src/pextlib1.0/Pextlib.c the comment describing 
the function NextuidCmd says it will "Find the first unused UID > 500" but it 
actually starts at the value of MIN_USABLE_UID which the configure script 
hardcodes as 500.


> So, depending on the order of creation, the same user has different uid (same 
> for groups). It is not generally a problem, but I don’t like it. Depending on 
> the order of actions on a system you get different uids for different 
> MacPorts-generated users, intermingled with created local users.
> 
> I’d like to tell macports to start at another number, to lessen the chance of 
> this.

There isn't a setting for the user to change this. If you want to change it, 
you'll have to edit the number in the MacPorts base configure script, 
reconfigure, and recompile.

Just make sure you don't use UIDs less than 500, which are reserved.

Is it possible to influence at what UID MacPorts start to create users?

[Gerben Wierda]

If you create local userson macOS, it starts with uid 501 and then goes up. 
(for network users it always (still?) started with 1025 and then goes up.

MacPorts, when it creates users, starts with 500 and then goes up.

So, depending on the order of creation, the same user has different uid (same 
for groups). It is not generally a problem, but I don’t like it. Depending on 
the order of actions on a system you get different uids for different 
MacPorts-generated users, intermingled with created local users.

I’d like to tell macports to start at another number, to lessen the chance of 
this.

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: What am I forgetting?

[Ryan Schmidt]

On Aug 14, 2019, at 13:19, Gerben Wierda wrote:

> Will installing the port remove my existing configuration in 
> /opt/local/etc/{nsd,unbound}?

That depends on whether the port "owns" those files. Ports should not own 
configuration files that the user is expected to edit, however it is up to the 
developer of the portfile to add code to the portfile to do that. You can check 
with "port contents nsd" to see what files it owns.

Re: What am I forgetting?

[Gerben Wierda]

> On 14 Aug 2019, at 15:13, Ryan Schmidt  wrote:
> 
> On Aug 13, 2019, at 03:25, Gerben Wierda wrote:
> 
>> Now, the only thing I have to do is to find a way to get my local revision 
>> back to 1, before I submit the patch. I have installed
>> 
>> Albus:nsd sysbh$ port installed
>> The following ports are currently installed:
>>  expat @2.2.7_0 (active)
>>  flex @2.6.4_0 (active)
>>  gettext @0.19.8.1_2 (active)
>>  libevent @2.1.10_0 (active)
>>  libiconv @1.16_0 (active)
>>  m4 @1.4.18_2 (active)
>>  ncurses @6.1_0 (active)
>>  nsd @4.1.22_0
>>  nsd @4.1.22_1
>>  nsd @4.2.1_0
>>  nsd @4.2.1_1
>>  nsd @4.2.1_2
>>  nsd @4.2.1_3
>>  nsd @4.2.1_5
>>  nsd @4.2.1_6 (active)
>>  openssl @1.0.2s_0 (active)
>>  unbound @1.9.2_0
>>  unbound @1.9.2_1 (active)
>>  zlib @1.2.11_0 (active)
>> 
>> If my update gets accepted, that would mean it would be revision 6. Is that 
>> bad? The revisions all come from my local tinkering because I know not how 
>> to force a build without changing revision.
>> 
>> I also want to clean up my installed versions. So nsd becomes
>> 
>>  nsd @4.2.1_0
>>  nsd @4.2.1_1 (active)
>> 
>> with that last one actually the current revision 6. How do I do that?
> 
> Uninstall the port. Edit the portfile to put the revision at 1. Install the 
> port if you like

Will installing the port remove my existing configuration in 
/opt/local/etc/{nsd,unbound}?

G

Re: Inconsistent registry

[Davide Liessi]

Reading more carefully I spotted the obvious typo:

>   p5.26-carp-clan @6.70.0_0 (active)
> $ port rdependents p5.26-carp-clean

Sorry for the noise.

Best wishes.
Davide

Inconsistent registry

[Davide Liessi]

Dear all,
I suspect that my MacPorts registry is in an inconsistent state:

$ port installed name:carp
The following ports are currently installed:
  p5.26-carp-clan @6.70.0_0 (active)
$ port rdependents p5.26-carp-clean
Error: Registry error: p5.26-carp-clean not registered as installed.

I always used the port command and I have never directly manipulated
the registry.
How could it happen?
Is uninstalling and reinstalling MacPorts and all ports the only solution?

Best wishes.
Davide

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F . Cunningham]

On 2019-08-14, at 7:52 AM, Kenneth F. Cunningham wrote:

>> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
>> error: shift expression '(1853123693 << 8)' overflows [-fpermissive]
>>  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
> 
> I have fixed this error on several occasions previously -- I believe by 
> adding "-fpermissive" as it suggests in the error.
> 
> I thought I had that committed somewhere in my LeopardPorts repo, but 
> apparently not. I know I have it somewhere, probably on my 10.5 Intel VM.
> 


Ah yes -- I put the info here (and a lot more harfbuzz analysis as well):



Ken

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
> error: shift expression '(1853123693 << 8)' overflows [-fpermissive]
>   kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),

I have fixed this error on several occasions previously -- I believe by adding 
"-fpermissive" as it suggests in the error.

I thought I had that committed somewhere in my LeopardPorts repo, but 
apparently not. I know I have it somewhere, probably on my 10.5 Intel VM.

Ken

Re: What am I forgetting?

[Rainer Müller]

On 14/08/2019 15.12, Ryan Schmidt wrote:
> 
> 
> On Aug 12, 2019, at 20:22, Mojca Miklavec wrote:
> 
>> If not, "sudo port install" or "sudo port upgrade" (without port name)
> 
> `port upgrade` will always find the port in the default tree. It will not 
> find the port in the local directory. So you don't want to use `port upgrade` 
> in this case. We've discussed this surprising behavior before...

Indeed, this is one of the oldest tickets. However, it is still stuck in the
design phase to define what the behavior should be...

https://trac.macports.org/ticket/15186

Rainer

Re: What am I forgetting?

[Ralph Seichter]

* Ryan Schmidt:

> `port install` will find the port in the local directory, if you don't
> specify a name, so that's what you should use.

Indeed. Personally, I also like to use "port clean --work --logs" while
working on a port, to ensure that previous (failed) install attempts did
not leave anything behind.

-Ralph

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> > I tried building with clang-3.7 but it doesn't work, because the port wants 
> > then to issue -stdlib=macports-libstdc++, which clang 3.7 does not 
> > understand.
>
> We didn't backport that feature to clang-3.7? I wonder why we didn't.

The supporting technology for macports-libstdc++ did not exist in llvm until 
the 3.9 release.

I backported it into llvm-3.8 for my own use on PPC 
 but there was 
no reason to make that available for MacPorts so I never submitted it (and 
clang-3.8 has been deleted from MacPorts anyway now).

Ken

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Mojca Miklavec]

On Wed, 14 Aug 2019 at 15:05, Ryan Schmidt wrote:
> On Aug 14, 2019, at 02:14, Riccardo Mottola wrote:
>
> > I tried building with clang-3.7 but it doesn't work, because the port wants 
> > then to issue -stdlib=macports-libstdc++, which clang 3.7 does not 
> > understand.
>
> We didn't backport that feature to clang-3.7? I wonder why we didn't.

At that time the patch took forever to merge even for the latest
version because everyone was afraid of the consequences or breakages,
and Jeremy did not provide feedback for a very long time.

At the end it was more like "it cannot do much harm if we only include
this in the experimental version", and from that point on we kept
adding it to all newer versions, and I don't remember any issues.

I assume there should be no harm in backporting it to older versions.

Mojca

Re: What am I forgetting?

[Ryan Schmidt]

On Aug 13, 2019, at 08:41, Gerben Wierda wrote:

> And the two ways this directory tree is going to be updated, git and port, 
> they do not conflict? What if I do some git work in the nsd directory and 
> then port updates it, aren’t my changes overwritten?

No, there is no conflict. No, your changes won't be overwritten.

If you were using a sync method that involves a tarball, such as the default 
rsync sync method, then yes, your changes would be overwritten. This is because 
to update your ports tree, MacPorts gets the new tarball, deletes the ports 
tree (including any changes you may have made there), and then untars the new 
tarball.

But when you use the git sync method, MacPorts updates it by using `git pull`, 
which preserves any edits you've made.

Re: What am I forgetting?

[Ryan Schmidt]

On Aug 13, 2019, at 08:24, Gerben Wierda wrote:

> That was it. It was on the manual page for local repositories, but this 
> directory tree was created using git via 
> https://trac.macports.org/wiki/WorkingWithGit where portindex is not 
> mentioned and I was following instructions there when I created the ‘dev’ 
> tree.

Please edit the wiki page if it is incomplete or wrong.

Re: What am I forgetting?

[Ryan Schmidt]

On Aug 13, 2019, at 03:25, Gerben Wierda wrote:

> Now, the only thing I have to do is to find a way to get my local revision 
> back to 1, before I submit the patch. I have installed
> 
> Albus:nsd sysbh$ port installed
> The following ports are currently installed:
>   expat @2.2.7_0 (active)
>   flex @2.6.4_0 (active)
>   gettext @0.19.8.1_2 (active)
>   libevent @2.1.10_0 (active)
>   libiconv @1.16_0 (active)
>   m4 @1.4.18_2 (active)
>   ncurses @6.1_0 (active)
>   nsd @4.1.22_0
>   nsd @4.1.22_1
>   nsd @4.2.1_0
>   nsd @4.2.1_1
>   nsd @4.2.1_2
>   nsd @4.2.1_3
>   nsd @4.2.1_5
>   nsd @4.2.1_6 (active)
>   openssl @1.0.2s_0 (active)
>   unbound @1.9.2_0
>   unbound @1.9.2_1 (active)
>   zlib @1.2.11_0 (active)
> 
> If my update gets accepted, that would mean it would be revision 6. Is that 
> bad? The revisions all come from my local tinkering because I know not how to 
> force a build without changing revision.
> 
> I also want to clean up my installed versions. So nsd becomes
> 
>   nsd @4.2.1_0
>   nsd @4.2.1_1 (active)
> 
> with that last one actually the current revision 6. How do I do that?

Uninstall the port. Edit the portfile to put the revision at 1. Install the 
port if you like.

Re: What am I forgetting?

[Ryan Schmidt]

On Aug 12, 2019, at 20:22, Mojca Miklavec wrote:

> If not, "sudo port install" or "sudo port upgrade" (without port name)

`port upgrade` will always find the port in the default tree. It will not find 
the port in the local directory. So you don't want to use `port upgrade` in 
this case. We've discussed this surprising behavior before...

But `port install` will find the port in the local directory, if you don't 
specify a name, so that's what you should use.

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Ryan Schmidt]

On Aug 14, 2019, at 02:14, Riccardo Mottola wrote:

> as a dependency, harfbuzz is being installed on my 10.5 64bit system.
> 
> The default picked up compiler is gcc6 and I get the following errors. I ask, 
> because I have seen this errors in other builds and even some of my own code, 
> it is in the system headers.
> 
> /opt/local/bin/g++-mp-6 -DHAVE_CONFIG_H -I. -I..  -pthread 
> -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include 
> -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
> -I/opt/local/include  -fno-rtti -pipe -Os -DHB_NO_PRAGMA_GCC_DIAGNOSTIC_ERROR 
> -D_GLIBCXX_USE_CXX11_ABI=0 -m64 -fno-exceptions -fno-threadsafe-statics 
> -fvisibility-inlines-hidden -MT test_ot_name-test-ot-name.o -MD -MP -MF 
> .deps/test_ot_name-test-ot-name.Tpo -c -o test_ot_name-test-ot-name.o `test 
> -f 'test-ot-name.cc' || echo './'`test-ot-name.cc
> In file included from 
> /System/Library/Frameworks/Security.framework/Headers/Security.h:57:0,
>  from 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSSharedFileList.h:32,
>  from 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:37,
>  from 
> /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:41,
>  from 
> /System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:20,
>  from hb-coretext.h:37,
>  from hb-coretext.cc:35:
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
> error: shift expression '(1853123693 << 8)' overflows [-fpermissive]
>  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
> error: enumerator value for 'kSecAuthenticationTypeNTLM' is not an integer 
> constant
>  kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:103:46: 
> error: shift expression '(1836281441 << 8)' overflows [-fpermissive]
>  kSecAuthenticationTypeMSN  = AUTH_TYPE_FIX_ ('msna'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:103:46: 
> error: enumerator value for 'kSecAuthenticationTypeMSN' is not an integer 
> constant
>  kSecAuthenticationTypeMSN  = AUTH_TYPE_FIX_ ('msna'),
>   ^
> /System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:104:46: 
> error: shift expression '(1685086561 << 8)' overflows [-fpermissive]
>  kSecAuthenticationTypeDPA  = AUTH_TYPE_FIX_ ('dpaa'),
> 
> <... and many more very similar ...>
> 
> 
> So probably either something can be tweaked when using gcc6 or it is too 
> "new" for the system headers?

I would guess that this "problem" (if it is one) slipped into the system 
headers because the version of gcc that was in use at the time did not check 
for this problem.

I would guess you can instruct gcc 6 not to consider this to be an error 
somehow.


> I tried building with clang-3.7 but it doesn't work, because the port wants 
> then to issue -stdlib=macports-libstdc++, which clang 3.7 does not understand.

We didn't backport that feature to clang-3.7? I wonder why we didn't.


> Clang-3.9 is no more and I am unable to get clang 5.0 on 10.5, but that is a 
> different issue, I suppose and will report it separately.

Re: ledger fails to build after boost upgrade to 1.70.0

[Kastus Shchuka]

Thank you, Chris! Much appreciated.

> On Aug 14, 2019, at 3:16 AM, Christopher Jones  
> wrote:
> 
> 
> Actually, fix was trivial.
> 
> https://github.com/macports/macports-ports/commit/087140b0f4e960a304d3d56708aa77989b441b16
> 
>> On 14 Aug 2019, at 11:02 am, Christopher Jones  
>> wrote:
>> 
>> Hi,
>> 
>> Looks like ledger does not yet support the updated boost.
>> 
>> please look for an open ticket at
>> 
>> https://trac.macports.org/wiki/Tickets
>> 
>> and if there is none for this issue, open one.
>> 
>> cheers Chris
>> 
>>> On 14 Aug 2019, at 6:40 am, Kastus Shchuka  wrote:
>>> 
>>> Hi,
>>> 
>>> After doing “port upgrade outdated” boost was upgraded to 1.70.0_0, and it 
>>> triggered rebuild of ledger @3.1.1_4.
>>> 
>>> The error in 
>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_finance_ledger/ledger/main.log
>>>  is this:
>>> 
>>> :info:configure -- Found PythonInterp: /opt/local/bin/python2.7 (found 
>>> version "2.7.16") 
>>> :info:configure -- Found PythonLibs: /opt/local/lib/libpython2.7.dylib 
>>> (found version "2.7.10") 
>>> :info:configure CMake Error at 
>>> /opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
>>> (message):
>>> :info:configure   Could NOT find Boost (missing: python) (found suitable 
>>> version "1.70.0",
>>> :info:configure   minimum required is "1.49.0”)
>>> 
>>> This is the version of boost that I have after upgrade:
>>> 
>>>  boost @1.70.0_0+no_single+no_static+python27 (active)
>>> 
>>> Am I missing something obvious here?
>>> 
>>> Thanks,
>>> 
>>> Kastus
>>> 
>>> 
>> 
> 

Re: ledger fails to build after boost upgrade to 1.70.0

[Christopher Jones]

Actually, fix was trivial.

https://github.com/macports/macports-ports/commit/087140b0f4e960a304d3d56708aa77989b441b16
 


> On 14 Aug 2019, at 11:02 am, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Looks like ledger does not yet support the updated boost.
> 
> please look for an open ticket at
> 
> https://trac.macports.org/wiki/Tickets 
> 
> 
> and if there is none for this issue, open one.
> 
> cheers Chris
> 
>> On 14 Aug 2019, at 6:40 am, Kastus Shchuka > > wrote:
>> 
>> Hi,
>> 
>> After doing “port upgrade outdated” boost was upgraded to 1.70.0_0, and it 
>> triggered rebuild of ledger @3.1.1_4.
>> 
>> The error in 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_finance_ledger/ledger/main.log
>>  is this:
>> 
>> :info:configure -- Found PythonInterp: /opt/local/bin/python2.7 (found 
>> version "2.7.16") 
>> :info:configure -- Found PythonLibs: /opt/local/lib/libpython2.7.dylib 
>> (found version "2.7.10") 
>> :info:configure CMake Error at 
>> /opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
>> (message):
>> :info:configure   Could NOT find Boost (missing: python) (found suitable 
>> version "1.70.0",
>> :info:configure   minimum required is "1.49.0”)
>> 
>> This is the version of boost that I have after upgrade:
>> 
>>  boost @1.70.0_0+no_single+no_static+python27 (active)
>> 
>> Am I missing something obvious here?
>> 
>> Thanks,
>> 
>> Kastus
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: ledger fails to build after boost upgrade to 1.70.0

[Christopher Jones]

Hi,

Looks like ledger does not yet support the updated boost.

please look for an open ticket at

https://trac.macports.org/wiki/Tickets 

and if there is none for this issue, open one.

cheers Chris

> On 14 Aug 2019, at 6:40 am, Kastus Shchuka  wrote:
> 
> Hi,
> 
> After doing “port upgrade outdated” boost was upgraded to 1.70.0_0, and it 
> triggered rebuild of ledger @3.1.1_4.
> 
> The error in 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_finance_ledger/ledger/main.log
>  is this:
> 
> :info:configure -- Found PythonInterp: /opt/local/bin/python2.7 (found 
> version "2.7.16") 
> :info:configure -- Found PythonLibs: /opt/local/lib/libpython2.7.dylib (found 
> version "2.7.10") 
> :info:configure CMake Error at 
> /opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
> (message):
> :info:configure   Could NOT find Boost (missing: python) (found suitable 
> version "1.70.0",
> :info:configure   minimum required is "1.49.0”)
> 
> This is the version of boost that I have after upgrade:
> 
>  boost @1.70.0_0+no_single+no_static+python27 (active)
> 
> Am I missing something obvious here?
> 
> Thanks,
> 
> Kastus
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

harfbuzz - strange compiler issues with gcc on 10.5

[Riccardo Mottola via macports-users]

Hi,

as a dependency, harfbuzz is being installed on my 10.5 64bit system.

The default picked up compiler is gcc6 and I get the following errors. I 
ask, because I have seen this errors in other builds and even some of my 
own code, it is in the system headers.


/opt/local/bin/g++-mp-6 -DHAVE_CONFIG_H -I. -I..  -pthread 
-I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include 
-I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
-I/opt/local/include  -fno-rtti -pipe -Os 
-DHB_NO_PRAGMA_GCC_DIAGNOSTIC_ERROR -D_GLIBCXX_USE_CXX11_ABI=0 -m64 
-fno-exceptions -fno-threadsafe-statics -fvisibility-inlines-hidden -MT 
test_ot_name-test-ot-name.o -MD -MP -MF 
.deps/test_ot_name-test-ot-name.Tpo -c -o test_ot_name-test-ot-name.o 
`test -f 'test-ot-name.cc' || echo './'`test-ot-name.cc
In file included from 
/System/Library/Frameworks/Security.framework/Headers/Security.h:57:0,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSSharedFileList.h:32,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:37,
 from 
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:41,
 from 
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:20,

 from hb-coretext.h:37,
 from hb-coretext.cc:35:
/System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
error: shift expression '(1853123693 << 8)' overflows [-fpermissive]

 kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
  ^
/System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:102:46: 
error: enumerator value for 'kSecAuthenticationTypeNTLM' is not an 
integer constant

 kSecAuthenticationTypeNTLM = AUTH_TYPE_FIX_ ('ntlm'),
  ^
/System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:103:46: 
error: shift expression '(1836281441 << 8)' overflows [-fpermissive]

 kSecAuthenticationTypeMSN  = AUTH_TYPE_FIX_ ('msna'),
  ^
/System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:103:46: 
error: enumerator value for 'kSecAuthenticationTypeMSN' is not an 
integer constant

 kSecAuthenticationTypeMSN  = AUTH_TYPE_FIX_ ('msna'),
  ^
/System/Library/Frameworks/Security.framework/Headers/SecKeychain.h:104:46: 
error: shift expression '(1685086561 << 8)' overflows [-fpermissive]

 kSecAuthenticationTypeDPA  = AUTH_TYPE_FIX_ ('dpaa'),

<... and many more very similar ...>


So probably either something can be tweaked when using gcc6 or it is too 
"new" for the system headers?



I tried building with clang-3.7 but it doesn't work, because the port 
wants then to issue -stdlib=macports-libstdc++, which clang 3.7 does not 
understand. Clang-3.9 is no more and I am unable to get clang 5.0 on 
10.5, but that is a different issue, I suppose and will report it 
separately.



Riccardo