Re: Set CC to clang++

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

Re: Set CC to clang++

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

Re: Set CC to clang++

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

Re: Set CC to clang++

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:

Re: error: thread-local storage is not supported

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

Set CC to clang++

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 ·

Re: error: thread-local storage is not supported

[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,

Re: error: thread-local storage is not supported

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

Re: error: thread-local storage is not supported

> 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

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

Re: error: thread-local storage is not supported

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.

libxml2 2.9.10 fixes some things

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