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.) >
smime.p7s
Description: S/MIME cryptographic signature
