Re: harfbuzz - strange compiler issues with gcc on 10.5

[Kenneth F. Cunningham]

> Since PPC does not have clang, it will be bitten by this issue.

PPC does not have this issue. Many details in the referenced harfbuzz ticket.

Ken

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Riccardo Mottola via macports-users]

Hi,

On 8/14/19 3:05 PM, Ryan Schmidt 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.



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.



3.7 can't handle that, the solution for me was to get 5.0 up and running 
- so no urgency. But enabling the -fpermissive flag for GCC only could 
be an interesting thing in the Portfile and avoid future headaches.



Riccardo

Re: harfbuzz - strange compiler issues with gcc on 10.5

[Riccardo Mottola via macports-users]

Hi all,

On 8/14/19 4:58 PM, Kenneth F. Cunningham wrote:

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):





I finally managed to avoid this problem because I was able to build 
clang 5.0 and then built harfbuzz with clang 5.0 and this worked fine.


Could we add -fpermissive only when using gcc? is the compiler type 
available? maybe something like compiler + mac version.


Since PPC does not have clang, it will be bitten by this issue.

Riccardo

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: 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: 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.