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 <[email protected]> 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 <[email protected]> wrote: >> >> >> On Mar 24, 2017, at 14:48, db <[email protected]> wrote: >> >>> On 24 Mar 2017, at 19:23, Ryan Schmidt <[email protected]> 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 <[email protected]> wrote: >>> >>> On 24 Mar 2017, at 19:21, Ryan Schmidt <[email protected]> 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.) >> >
