Host Versus MacPorts lib[std]c++ [was: Re: Fortran recipe]

[Jeremy Huddleston Sequoia]

On Aug 28, 2013, at 20:38, Michael Dickens <michaelld at macports.org> wrote:

> On Wed, Aug 28, 2013, at 10:06 PM, Jeremy Huddleston Sequoia wrote:
>> I think trying to move things over to MacPorts' libstdc++ would be a
>> waste of time.  We should try to reduce the configuration space as much
>> as possible (to just libc++).
> 
> OK; fine. I'm clearly out of the loop when it comes to MacPorts versus
> host lib[std]c++. I do not generally write or debug code at that level;
> I just use it and see how well it works or does not work.  It seems that
> moving away from libstdc++ is your (the project's?) desired goal, moving
> towards just libc++.  Fine; I'm OK with that. But, again with my limited
> understanding, given the number of ports which require libstdc++
> (Apple's or MacPorts' GCC) I don't see a good way to do the move to just
> libc++ tomorrow, or even this month, or probably even this year.  I
> believe that libstdc++ will have to be dealt with by MacPorts for quite
> a while to come.

The problem is that more and more ports are going to be requiring C++11 features which means they will require a runtime that supports it (that is either MP's libstdc++ or libc++).  MP's libstdc++ is out of the question as far as I'm concerned, so that leaves libc++.

Our ports are not "using libstdc++" they're "using the C++ runtime selected by the C++ compiler".  The switch to libc++ on Lion and ML is as simple as setting configure.cxxflags to contain "-stdlib=libc++" when the compiler is clang, revbumping all the C++ ports, and dealing with fallout in ports that don't support libc++.  That's something I've been doing on and off for the past couple years anyways, and we're fairly close (at least for the ports I use).

> The MacPorts end-user, generally speaking, cares that the ports they
> need/want can be installed and used as expected/desired, to not be
> broken; they do not generally care which lib[std]c++ library is used.

Yes.  Exactly.  They want their port to install.  If their port depends on C++11, they are currently screwed (see mkvtoolnix for example).

> I see the scheme I wrote as realizable, in short order, and providing high
> end-user functionality.  Maybe I'm wrong about all of these?

The problem is that if a user wants to use the host compiler to link their own project against MacPorts libraries... they need to remember to do that post-install cleanup with install_name_tool as well.  I don't think that's particularly safe.

> If not,
> then I'd love to see this scheme, or something equivalent to it,
> implemented sooner rather than later (by me if necessary, though I
> haven't a clue how to do the changes so it will take me much longer than
> others who do have a clue) and then take the time necessary to figure
> out how to robustly transition to using just libc++.

Using libc++ is quite simple (see above).  The problem is triggering all the necessary port rebuilds.

> My goal in all of this is really just to better understand the
> lib[std]c++ stuff, which clearly is a multi-faceted issue.  I think I'm
> understanding more of that now, though I also think I have a ways to go.

It's been a few months now since I tried using libc++ on ML.  I'll nuke all my ports on one of my ML machines and rebuild to make sure nothing has regressed with ML/libc++.  I think the bigger problems are identifying everything that needs to be revbumped and fixing ports that use C++ and currently compiler.blacklist clang.

--Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130828/a80dcf49/attachment-0001.p7s>