On Sun, Sep 7, 2014 at 12:52 AM, Ryan Schmidt wrote:
> On Sep 6, 2014, at 5:51 AM, Mojca Miklavec wrote:
>
>> I already argued that we really need a libc++-based buildbot for 10.6-10.8.
>>
>> From what I understood all we need is a fix in binary package
>> signature + time and resources to set up the buildbots. Once the
>> buildbots run, people can start testing and switching to libc++. Once
>> we get to a satisfactory support, we can recommend everyone to switch
>> and retire the libstdc++-based buildbots if needed.
>>
>> Switching from libstdc++ to libc++ would be equal to switching from
>> 10.x to 10.(x+1). (Nice to automate one day, but people should switch
>> manually for now and reinstall everything from scratch.)
>
> Anything where we're asking people to manually reinstall things is, IMHO, a
> niche situation. My guess is that a few very interested and involved people
> subscribe to the macports-users list, but that the vast majority of MacPorts
> users just use it and never communicate with the community. Those users
> should be given a smooth upgrade experience as well; they shouldn't have to
> seek out help to get the best MacPorts experience; it should just work.
I never suggested doing dramatic changes that would *require* users to
do a manual upgrade. But at least to those users that start
complaining about mkvtoolnix crashing, we would have a satisfactory
answer: go to this wiki page and follow instructions to switch to
libc++.
Switching to libc++ only means changing a single setting in
macports.conf. (For better support this also means changing the binary
signature depending on which libc++/libstdc++ library is being used
and setting up a buildbot.)
Support for libstdc++ can stay (to the extent that port maintainers
will support it – same as with support for Tiger).
It would be weird if we forced users to switch to a different runtime.
If nothing else I bet there are users who would really want to keep
using libstdc++ for various reasons (easier to compile [own] software
manually etc.) and don't bother about C++11.
But it would be really really nice to create a mechanism that:
- remembers which ports are installed and which ones are requested
- deactivates (and possibly uninstalls) all ports
- installs all the ports again
which could be applied in both situations:
- switching to a different library or changing some other options in
macports.conf (maybe change applications_dir or frameworks_dir or so)
- upgrading the OS
But that's not *required* to improve support for libc++ on older OSes.
> Do we already record the C++ runtime in the registry with each installed
> port? If not, we should do that, in addition to getting it into the binary
> filenames. And just as we do for architectures, maybe we should have an
> indication for software that doesn't use any C++ runtime ("nocxx"?).
This is something that I'm not familiar with at all. I would be very
grateful if some other developer would add the necessary code. I'm
willing to keep testing and fixing ports ...
> Presumably we would (or possibly already do) record in the registry the value
> of configure.cxx_stdlib. But it would be nice if we would also automatically
> check (somehow: either as part of the install, or maybe as part of
> rev-upgrade) that the specified C++ library is the one that actually got
> used. Similarly, it would be nice if we checked that the architectures we
> recorded are the architectures that actually got built.
>
>> The libc++-based MacPorts works well on < 10.9 already for most
>> packages.
>
> Good to know many ports have worked, but I still suspect there are many ports
> you either haven't tried or haven't noticed the situations where libstdc++ is
> still being used even though libc++ was requested. An automated check would
> help with this.
Most definitely there are other/more problems to be expected. If we
add a buildbot, it will be a lot easier to get more people to test.
Mojca
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
