building from source with libc++

[db]

I opened #53866, but forgot the version in the subject, @1.6.4, and the exact version of ML, which is 10.8.5 — if you can amend it for me.

On 27 Mar 2017, at 05:49, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:

> libX11 has no C++ code, so the error probably has nothing to do with the C++ library chosen.
> 
> Please do open a ticket with whatever relevant data you can provide.
> 
>> On Mar 24, 2017, at 14:24, Ryan Schmidt <ryandesign at macports.org> wrote:
>> 
>> 
>> On Mar 24, 2017, at 14:48, db <iamsudo at gmail.com> wrote:
>> 
>>> On 24 Mar 2017, at 19:23, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>> I agree that ticket describes the error you encountered. It was closed because nobody could explain it and the problem went away for the reporter. You could re-open it and add your new information to it.
>>> 
>>> Re-open #52335 while it's for different OS and Xcode versions?
>> 
>> Or file a new ticket, making reference to the old one. It's the same error message, so it may well be the same cause. Or it may not. I don't know.
>> 
>>> Fwiw, I could try building xorg-libX11 from source but with libstdc++, first.
>> 
>> There are two possibilities. 1. xorg-libX11 doesn't build when built for a non-default c++ stdlib. If you think this is the problem, then file a ticket. 2. There is a problem on your computer that prevents xorg-libX11 from building in any situation. If you believe that is the case, then try to build it with libstdc++. (We already know it builds fine with libstdc++ on 10.8 on our automated build system.)
>> 
>> 
>>> On Mar 24, 2017, at 14:50, db <iamsudo at gmail.com> wrote:
>>> 
>>> On 24 Mar 2017, at 19:21, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>> Upgrading to a version of macOS with libc++ as default (10.9 and later) will probably make your MacPorts life easier, but it's up to you of course.
>>> 
>>> Despite the overall lower quality and usability of 10.9+, I don't see how, since MP in 10.8 can be configured to use libc++.
>> 
>> I can't speak to the lower quality and usability that you perceive. I can only tell you that build systems are finicky things, many of them are nonstandard, and there are probably many of our ports that do not properly pass the c++ stdlib flags to the build system, which will lead to problems most port developers have not encountered, so you may be encountering them and having to help test and resolve them.
>> 
>> 
>>>>> problems with python2_select (needed base updated)
>>>> What do you mean?
>>> 
>>> I don't remember the exact error, but it failed to compile — it succeeded when I upgraded the base from 2.3.x to 2.4.1.
>> 
>> Ok, probably the "-q" flag we added to reinplace in 2.4.0. We never support old versions of MacPorts. Always use the current version.
>> 
>> 
>>>>> and xorg-libX11 (attached config.log), which is working fine in another system with same versions.
>>>> Another 10.8 system that you've also switched to libc++? Any differences between the two systems you can think of?
>>> 
>>> OS X 10.8.5, Xcode 5.1.1, MP 2.4.1 — no differences that come to mind.
>> 
>> If the other 10.8 system also was switched to libc++ then I would believe there is a problem with this system that does not exist on your other 10.8 system. The problem could be an older version of Xcode, or mismatched or missing version of the command line tools.
>> 
>> 
>>>> Not really. You could run into build problems. If you do, and it doesn't seem to be because of something unique to your system, please let us know.
>>> 
>>> Should I expect to encounter problems when switching to building from source with libc++ for the same ports whose binaries work fine with libstdc++? 
>> 
>> Certainly; libc++ on 10.8 is a nonstandard configuration that most MacPorts developers have never tested; as such, you're bound to run into as-yet-undiscovered problems that will need to be diagnosed and fixed by someone.
>> 
>> In addition, you can run into the conflicts anyone could run into when building from source that can arise when building software on non-pristine systems. (Our binaries are produced on our buildbot system which is "pristine" because it has no third-party software installed and no MacPorts ports active when each port is built, ensuring there can be no conflicts.)
>> 
>