compilers on Lion

Sat Sep 8 20:45:56 UTC 2018

> Folks,
> 
> 
> macports newbie here :-)
> 
> I'm running a Lion box and I'm running macports from git, which works
> just fine.  I've followed the advice on LibcxxOnOlderSystems and did
> 
>   cxx_stdlib         libc++
>   buildfromsource    always        

This is a reasonable choice for Lion, and I recommend it, but it does have some setbacks for you.

The benefit with this setup is that Lion looks very much like the newer macOS systems, and so therefore most Portfiles will "just work". Also, any development you do in Portfiles or software on that system will very likely transfer to newer macOS versions. This is why I use this setup myself (on SnowLeopard).

One downside of going with libc++ is that none of the buildbots are set up this way, so you will spend a great deal of time building stuff.

There is another downside to ponder as well, a bit more complex to explain. By going with libc++, you more or less lose compatibility with gcc builds -- a somewhat advanced c++ stdlib discussion is coming:

By default Lion is set up to link against /usr/lib/libstdc++; clang can build against this quite easily, as can gcc-*. So if you say with cxx_stdlib libstdc++ (the default) in fact you can use either gcc* or clang* to build your ports, and they will work together perfectly well. Which opens up a few doors building things with gcc* that might otherwise be closed.

For c++11 or newer, the old libstdc++ in /usr/lib/ on Lion does not support c++11, and can't be upgraded. However, macports is designed to install libgcc (currently version 8) into ${prefix}/lib and _that_ libstdc++ works great for both clang (3.9 or newer) and gcc (5 or newer) to link against. So all is good again. gcc 5 or newer link against that by default.

To force clang (3.9 or newer) to link against that newer version of libstdc++ you pass the flag -stdlib=macports-libstdc++, and to make the software compatible with the old /usr/lib/libstdc++ you pass -D_GLIBCXX_USE_CXX11_ABI=0 in the cxx flags. Both of these things are done in the background for users when Portfiles include a certain "PortGroup", the cxx11 1.1.

There is a theoretical issue doing this wherein an object might be created by software that used libstdc++ in /usr/lib and then somehow that object were deleted by software that is linked against the libstdc++ in ${prefix}/lib -- I have never seen this happen, nobody has ever reported a ticket about it, and perhaps the probability of that is so low it will never happen. But apparently it is a theoretical problem that could occur.

There _is_ indeed a way for gcc to build against libc++, as you pointed out in a subsequent email, and one of our contributors (Rene) went to the trouble of patching gcc to allow it to accept the "-stdlib=libc++" flag to make this easy. But in the end, he could not get any purchase for his work either from MacPorts or from gcc, and so it went dormant.

You can build software with gcc without concerns on MacPorts if it doesn't use c++, or if it doesn't link against any other libraries or supply libraries for other software to use. I use this trick often enough for my own use, using gcc7 to build software on Snow Leopard that needs thread_local storage (thread_local is not available on SnowLeopard when using clang).

> .
> 
> Attached you can see the list of software that I've installed so far.
> In particular, I've installed `gcc8' and set it up as the default gcc
> compiler, which I think is a good choice later on for lilypond-devel,
> which doesn't like to be compiled with clang, AFAIK.  As the
> maintainer of FreeType and ttfautohint I'm also curious whether my
> stuff works correctly – there are some glitches here and there which I
> want to fix eventually with macport push requests as soon as I'm more
> acquainted with the system.
> 
> Note that I'm an old GNU/Linux user; I only work on the Mac for
> software testing.
> 
> Now to my problems.  I stumbled across various issues for which I
> can't find an explanation or solution in the net.  Some of them should
> probably be directed directly to the tracker I guess...
> 
> * The concept of `subports' is not mentioned in `man port'.  Where is
>   it described?  I can more or less deduce now how it works, but a
>   formal description would be nice.
> 
> * I'm missing the ability to say
> 
>     port select --set emacs emacs23   .
> 
>   I see that there is https://trac.macports.org/ticket/56949, but even
>   then it would be nice to have this since Lion comes with its own
>   emacs binary.
> 
> * It's impossible to guess the difference between the `emacs' and
>   `emacs-app' port from the output of `port info'.  The description of
>   the former should mention that it is TTY only, while the latter uses
>   the GUI.  Additionally, `emacs --help' contains a bunch of options
>   for controlling the (X11) display, which are completely useless of
>   course if Emacs can only be run on the terminal...
> 
> * Saying
> 
>     port install poppler
> 
>   returns
> 
>     --->  Computing dependencies for poppler
>     The following dependencies will be installed: 
>      clang-3.7
>      clang-3.9
>      clang-4.0
>      clang-5.0
>      libomp
>      llvm-3.7
>      llvm-3.9
>      llvm-4.0
>      llvm-5.0    .
> 
>   For me, this looks like a bad joke!  *Four* compilers are necessary
>   for poppler?  Additionally, it seems that since clang 3.8 it is no
>   longer necessary to have a separate `libomp' package at all, cf.
> 
>     https://openmp.llvm.org/    .
> 
>   Theoretically, my already installed gcc8 should compile this package
>   just fine, right?  Why doesn't `port' consider it?  Looking into
>   poppler's Portfile I don't see any compilers blacklisted.

newer versions of gcc can compile llvm and clang just fine. I use gcc6 to compile clang-3.8 on 10.4 and 10.5 PPC. But the Portfiles in MacPorts are set up and tested to build clang with an older clang, and they are not going to be changed at this point.

> 
>   Please advise how to escape this dependency hell...

It is probably not worth fighting this battle, IMHO. Sometimes a specific version of clang is the only one that will work to build a certain port. Sometimes the Portfiles are a bit old and just haven't been updated  / tested against newer clang versions to see if they work. But you will spend a lot more time straightening this out than you would just installing a compiler farm. Here's what I have installed, for example:

$ port -v installed | grep llvm
  llvm-3.4 @3.4.2_12+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-08-19T19:58:23-0700'
  llvm-3.5 @3.5.2_9 (active) platform='darwin 10' archs='x86_64' date='2017-08-19T20:26:08-0700'
  llvm-3.7 @3.7.1_4 (active) platform='darwin 10' archs='x86_64' date='2018-06-03T23:56:41-0700'
  llvm-3.9 @3.9.1_5+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-10-22T11:10:27-0700'
  llvm-4.0 @4.0.0_0 (active) platform='darwin 10' archs='x86_64' date='2017-05-08T12:52:56-0700'
  llvm-5.0 @5.0.1_0+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-12-23T23:18:10-0800'
  llvm-6.0 @6.0.1_0 (active) platform='darwin 10' archs='x86_64' date='2018-08-22T21:11:54-0700'
  llvm-7.0 @7.0.0rc2_0 (active) platform='darwin 10' archs='x86_64' date='2018-09-03T23:29:34-0700'
  llvm_select @2_0 (active) platform='darwin 10' archs='noarch' date='2016-08-28T17:16:45-0700'

> 
> * Where can I get a concise and up-to-date description of portfiles?
>   `portfiles.7' seems to be heavily out of date...
> 
> I will certainly find more issues soon, but this e-mail is already too
> long :-)
> 
> 
>     Werner

Glad to have you on board!

Ken

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180908/80aa6ac7/attachment.html>