Re: Set CC to clang++

[Steven Smith]

I’m trying to build jsonnet  (dependency of 
a larger project).

jsonnet fails to build on macOS with the exact same error others observe, e.g. 
.

> Undefined symbols for architecture x86_64:
> "_jsonnet_destroy", referenced from:
…

If the CC=clang++ hack thing doesn’t work, I’l just commit the whole project 
and show the error in the build bot.


> On Nov 21, 2019, at 20:49, Joshua Root  wrote:
> 
> On 2019-11-22 12:18 , Steven Smith wrote:
>> Thanks. I’m just trying to hack around the error:
>>> |Undefinedsymbols forarchitecture x86_64|
> 
> The important thing is which symbols are missing and why. Seeing the
> exact link command would be useful. Can you share a build log?



smime.p7s
Description: S/MIME cryptographic signature

Re: Set CC to clang++

[Joshua Root]

On 2019-11-22 12:18 , Steven Smith wrote:
> Thanks. I’m just trying to hack around the error:
>> |Undefinedsymbols forarchitecture x86_64|

The important thing is which symbols are missing and why. Seeing the
exact link command would be useful. Can you share a build log?

> Another possible solution is:
>> add -stdlib=libstdc++ to the linking command
> 
> See:
> https://stackoverflow.com/questions/19637164/c-linking-error-after-upgrading-to-mac-os-x-10-9-xcode-5-0-1
> 
> I’ll try both, and go with the least-yuck one that works.
> 
> What’s the Portfile directive to add -stdlib=libstdc++ to the linker?

We always add that to CXXFLAGS when using clang. The build system should
be using "$CXX $CXXFLAGS $LDFLAGS ..." to link C++ code, but if it isn't
and you need to add -stdlib to LDFLAGS, you can do it like this:



- Josh

Re: Set CC to clang++

[Steven Smith]

Thanks. I’m just trying to hack around the error:
> Undefined symbols for architecture x86_64


Another possible solution is:
> add -stdlib=libstdc++ to the linking command


See: 
https://stackoverflow.com/questions/19637164/c-linking-error-after-upgrading-to-mac-os-x-10-9-xcode-5-0-1

I’ll try both, and go with the least-yuck one that works.

What’s the Portfile directive to add -stdlib=libstdc++ to the linker?

> On Nov 21, 2019, at 19:46, Joshua Root  wrote:
> 
> On 2019-11-22 09:35 , Steven Smith wrote:
>> 
>> CC=/usr/bin/clang++
>> 
>> 
>> Error on the Mac: Undefined symbols for architecture x86_64 · Issue #285 · 
>> nlohmann/json
>> https://github.com/nlohmann/json/issues/285#issuecomment-348090484
> 
> Is the build system really using $CC to compile C++ code? The usual
> convention is that CC is the C compiler and CXX is the C++ compiler.
> Naturally using the wrong one will cause problems.
> 
> Sticking to the convention is greatly preferable, but if for some reason
> you really need to name a C++ compiler in CC, this will do it:
> 
> # Yuck
> configure.cc${configure.cxx}
> 
> - Josh


smime.p7s
Description: S/MIME cryptographic signature

Re: Set CC to clang++

[Joshua Root]

On 2019-11-22 09:35 , Steven Smith wrote:
> I must set the clang compiler to clang++ or g++ to avoid some ld symbol 
> mangling issue (see below).
> 
> What’s the right Portfile directive to do this?
> 
> Effectively, I believe that I need:
> 
> CC=/usr/bin/clang++
> 
> 
> Error on the Mac: Undefined symbols for architecture x86_64 · Issue #285 · 
> nlohmann/json
> https://github.com/nlohmann/json/issues/285#issuecomment-348090484

Is the build system really using $CC to compile C++ code? The usual
convention is that CC is the C compiler and CXX is the C++ compiler.
Naturally using the wrong one will cause problems.

Sticking to the convention is greatly preferable, but if for some reason
you really need to name a C++ compiler in CC, this will do it:

# Yuck
configure.cc${configure.cxx}

- Josh

Re: error: thread-local storage is not supported

[Ken Cunningham]

Well, I’ll be hornswaggled.

Indeed it appears the compiler.thread_local_storage option in MacPorts is well 
and truly broken. It basically only works on 10.6 and less (which is where I 
often am, so I guess it always worked for me).

Marcus forgot to blacklist command_line clangs < 800. 

We’ll have to get that fixed.

>

Ken



> On Nov 21, 2019, at 11:42 AM, Renee Otten  wrote:
> 
> [sorry forgot to reply to the list earlier]
> 
> Thanks Ken, I am not sure if I can be of much help here - if you’d be willing 
> to take a look that would be great! For now I’ll just blacklist clang below 
> version 8.
> 
> Best,
> Renee
> 
> 
>> On Nov 21, 2019, at 12:52 PM, Ken Cunningham 
>> mailto:ken.cunningham.web...@gmail.com>> 
>> wrote:
>> 
>> yes, clang 800+ supported thread_local.
>> 
>> the open-source clangs support thread_local using libc++ way back, but 
>> certainly macports-clang-5.0+. 
>> 
>> the c++11 gcc versions support it as well, using macports-installed 
>> libstdc++.
>> 
>> All of that blacklisting logic is incorporated into Marcus' 
>> compiler.thread_local command, and the guts are in 'portconfigure.tcl'. The 
>> whole idea was to do it once there correctly, and then everyone could use 
>> that instead of figuring it out themselves.
>> 
>> So -- if  that is not being honoured in the build, something weird must be 
>> going on to make this build ignore base.
>> 
>> That's what I'll have to help sort out, using a VM or real system running 
>> those OS versions.
>> 
>> Ken
>> 
>> 
>> 
>> On 2019-11-21, at 9:35 AM, Renee Otten wrote:
>> 
>>> hi Ken, 
>>> 
>>> 
>>> see commits the following commits:
>>> 
>>> https://github.com/macports/macports-ports/commit/d6e27064e928b43d412618ac7227cc016e461738
>>>  
>>> 
>>> https://github.com/macports/macports-ports/commit/c9e9e2a6263bbf9d915d9ba61877c80eed1a3089
>>>  
>>> 
>>> 
>>> in the last commit, doing compiler.blacklist-append {clang < 700} does make 
>>> it build on OS X 10.8 and 10.9, but not on 10.10 yet, because there it uses 
>>> Clang “700.1.81”
>>> 
>>> I’d appreciate your help with it, perhaps the issue is actually different 
>>> and I don’t understand it correctly. 
>>> 
>>> Thanks again!
>>> Renee
> 

Set CC to clang++

[Steven Smith]

I must set the clang compiler to clang++ or g++ to avoid some ld symbol 
mangling issue (see below).

What’s the right Portfile directive to do this?

Effectively, I believe that I need:

CC=/usr/bin/clang++


Error on the Mac: Undefined symbols for architecture x86_64 · Issue #285 · 
nlohmann/json
https://github.com/nlohmann/json/issues/285#issuecomment-348090484

smime.p7s
Description: S/MIME cryptographic signature

Re: error: thread-local storage is not supported

[Renee Otten]

[sorry forgot to reply to the list earlier]

Thanks Ken, I am not sure if I can be of much help here - if you’d be willing 
to take a look that would be great! For now I’ll just blacklist clang below 
version 8.

Best,
Renee


> On Nov 21, 2019, at 12:52 PM, Ken Cunningham 
>  wrote:
> 
> yes, clang 800+ supported thread_local.
> 
> the open-source clangs support thread_local using libc++ way back, but 
> certainly macports-clang-5.0+. 
> 
> the c++11 gcc versions support it as well, using macports-installed libstdc++.
> 
> All of that blacklisting logic is incorporated into Marcus' 
> compiler.thread_local command, and the guts are in 'portconfigure.tcl'. The 
> whole idea was to do it once there correctly, and then everyone could use 
> that instead of figuring it out themselves.
> 
> So -- if  that is not being honoured in the build, something weird must be 
> going on to make this build ignore base.
> 
> That's what I'll have to help sort out, using a VM or real system running 
> those OS versions.
> 
> Ken
> 
> 
> 
> On 2019-11-21, at 9:35 AM, Renee Otten wrote:
> 
>> hi Ken, 
>> 
>> 
>> see commits the following commits:
>> 
>> https://github.com/macports/macports-ports/commit/d6e27064e928b43d412618ac7227cc016e461738
>>  
>> 
>> https://github.com/macports/macports-ports/commit/c9e9e2a6263bbf9d915d9ba61877c80eed1a3089
>>  
>> 
>> 
>> in the last commit, doing compiler.blacklist-append {clang < 700} does make 
>> it build on OS X 10.8 and 10.9, but not on 10.10 yet, because there it uses 
>> Clang “700.1.81”
>> 
>> I’d appreciate your help with it, perhaps the issue is actually different 
>> and I don’t understand it correctly. 
>> 
>> Thanks again!
>> Renee

Re: error: thread-local storage is not supported

[Ken Cunningham]

Let me say more

Every MacOS system supports thread_local storage, from 10.4 Tiger PPC on up.

Up to now, the base thread_local specifier introduced in MacPorts 2.6 has 
worked beautifully.

There is no reason to manually specifiy any compiler other than that command.

There is no reason to disable thread_local on any systems.

I'm happy  to help out if you are having issues, as I enabled thread_local on 
most of those systems, and have intimate knowledge of how it works.

Best,

Ken

Re: error: thread-local storage is not supported

[Ken Cunningham]

> Clang 5 and above do support this () 

Clang 5 and above do support thread_local storage.

what issue are you having?

Ken

Re: error: thread-local storage is not supported

[Chris Jones]

yes, just go with manually blacklisting compilers as required...

Might also be useful to submit a github issue against base, to discuss 
improving things there.


Chris

On 21/11/2019 1:30 pm, Renee Otten wrote:

Thank you Josh.

Unfortunately that doesn’t help as the same compilers are selected on 
OSX 10.8-10.10 and, therefore, the build still fails. It seems to me 
that base thinks that Clang 5 and above do support this () .So it makes 
sense that these compilers are used but it doesn’t seem to work. For now 
I think I’ll just switch the option off for older OS X versions or try 
to blacklist Clang < 7 and see it that helps.


Thanks,
Renee


On Nov 20, 2019, at 10:22 PM, Joshua Root > wrote:


On 2019-11-21 13:38 , Renee Otten wrote:

dear all,


one of the PRs I just merged
(https://github.com/macports/macports-ports/pull/5848) fails on OS X
10.8, 10.9, and 10.10 with the error "error: thread-local storage is not
supported for the current target” (with AppleClang version 5.1, 6.0, and
7.0, respectively). On 10.7 it works
again because /opt/local/bin/clang++-mp-9.0 is used as compiler, I
assume because of the "compiler.cxx_standard 2011” statement.

Looking at other Portfiles there seem to be two approaches to resolve 
this:

1. if ${os.major} < 11, disable “thread_local” which is doable for the
port in question, but it will then also be disabled on 10.7 where is
seems to work now
2. blacklists compilers using "compiler.blacklist-append {clang < 700}”

Is there an opinion (or even consensus) about what is the preferred way
of doing this?


You are supposed to be able to set `compiler.thread_local_storage yes`
and have it Just Work, but I don't know how accurate base's idea of
which compilers versions can be used is.

- Josh

Re: error: thread-local storage is not supported

[Renee Otten]

Thank you Josh. 

Unfortunately that doesn’t help as the same compilers are selected on OSX 
10.8-10.10 and, therefore, the build still fails. It seems to me that base 
thinks that Clang 5 and above do support this () .So it makes sense that these 
compilers are used but it doesn’t seem to work. For now I think I’ll just 
switch the option off for older OS X versions or try to blacklist Clang < 7 and 
see it that helps.

Thanks,
Renee


> On Nov 20, 2019, at 10:22 PM, Joshua Root  wrote:
> 
> On 2019-11-21 13:38 , Renee Otten wrote:
>> dear all, 
>> 
>> 
>> one of the PRs I just merged
>> (https://github.com/macports/macports-ports/pull/5848) fails on OS X
>> 10.8, 10.9, and 10.10 with the error "error: thread-local storage is not
>> supported for the current target” (with AppleClang version 5.1, 6.0, and
>> 7.0, respectively). On 10.7 it works
>> again because /opt/local/bin/clang++-mp-9.0 is used as compiler, I
>> assume because of the "compiler.cxx_standard 2011” statement. 
>> 
>> Looking at other Portfiles there seem to be two approaches to resolve this:
>> 1. if ${os.major} < 11, disable “thread_local” which is doable for the
>> port in question, but it will then also be disabled on 10.7 where is
>> seems to work now
>> 2. blacklists compilers using "compiler.blacklist-append {clang < 700}”
>> 
>> Is there an opinion (or even consensus) about what is the preferred way
>> of doing this? 
> 
> You are supposed to be able to set `compiler.thread_local_storage yes`
> and have it Just Work, but I don't know how accurate base's idea of
> which compilers versions can be used is.
> 
> - Josh

libxml2 2.9.10 fixes some things

[Joshua Root]

1. xml2-config now has a --dynamic option that can be used with --libs.
This should always be used when linking dynamically (as we almost always
are). With this flag available you don't have to switch to pkg-config to
avoid overlinking.

2. Along with the new upstream version, I added a patch to hide the icu
C++ API when not using C++11 or newer. That means dependents aren't
forced to use C++11 when they're just trying to use libxml2's C API and
don't even use icu.

So if you added a C++11 requirement to any ports purely because of build
failures in icu headers via libxml2, you can revert that now.

- Josh