<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><pre></pre><blockquote type="cite"><pre>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 </pre></blockquote><div><br></div><div>This is a reasonable choice for Lion, and I recommend it, but it does have some setbacks for you.</div><div><br></div><div>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).</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><blockquote type="cite"><pre>.
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 <a href="https://trac.macports.org/ticket/56949,">https://trac.macports.org/ticket/56949,</a> 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.
<a href="https://openmp.llvm.org/">https://openmp.llvm.org/</a> .
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.
</pre></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><br><blockquote type="cite"><pre>
Please advise how to escape this dependency hell...
</pre></blockquote><div><br></div><div>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:</div><div><br></div><div><div>$ port -v installed | grep llvm</div><div> llvm-3.4 @3.4.2_12+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-08-19T19:58:23-0700'</div><div> llvm-3.5 @3.5.2_9 (active) platform='darwin 10' archs='x86_64' date='2017-08-19T20:26:08-0700'</div><div> llvm-3.7 @3.7.1_4 (active) platform='darwin 10' archs='x86_64' date='2018-06-03T23:56:41-0700'</div><div> llvm-3.9 @3.9.1_5+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-10-22T11:10:27-0700'</div><div> llvm-4.0 @4.0.0_0 (active) platform='darwin 10' archs='x86_64' date='2017-05-08T12:52:56-0700'</div><div> llvm-5.0 @5.0.1_0+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-12-23T23:18:10-0800'</div><div> llvm-6.0 @6.0.1_0 (active) platform='darwin 10' archs='x86_64' date='2018-08-22T21:11:54-0700'</div><div> llvm-7.0 @7.0.0rc2_0 (active) platform='darwin 10' archs='x86_64' date='2018-09-03T23:29:34-0700'</div><div> llvm_select @2_0 (active) platform='darwin 10' archs='noarch' date='2016-08-28T17:16:45-0700'</div></div><div><br></div><blockquote type="cite"><pre>
* 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
</pre></blockquote><div><br></div>Glad to have you on board!<div><br></div><div>Ken<br><div><br></div></div></body></html>