On Nov 1, 2017, at 11:29, Mojca Miklavec wrote: > I'm currently trying to fix wxWidgets-3.0 in various ways. One of the > problems of the latest release is that it compiles fine with both > clang >= 500 and llvm-gcc. If I blacklist clang < 500 on Lion, it will > fallback to llvm-gcc which works in principle, but I don't know > whether it makes more sense to compile with, say, clang 3.4, or with > llvm-gcc. Suggestions? > > The additional complication is that any port which builds against > wxWidgets needs to use (more or less) the same compiler for both > compiling wxWidgets and the port that depends on it. Add to that that > ports that need both perl and wxWidgets probably need a compatible > compiler for all three? > > If I just blacklist one compiler for wxWidgets (but not for the ports > depending on it), I'll get a build failure on any other port that > builds against it. That's partly because wxWidgets does some testing > of compiler features and writes some of the results to the headers > which are then included in the sources of dependent software. (I > believe the reason for a failure of clang 425 on 10.7 is just some > incorrectly implemented test, but I'm not too eager to debug that if I > can simply switch the complier and get it working.) > > At least I'm sure that the build of dependent ports fails if wxWidgets > is built with a more capable compiler. I'm not sure whether things > work out of the box if one uses a less capable compiler for compiling > wxWidgets and then some C++11 capable compiler for a dependent port, > but I expect problems as well.
That sounds terrible. If this is true, then I think you should bring this to the attention of the wxWidgets developers and explain to them that this is not usable. It's just not possible to guarantee that all ports that want to use wxWidgets will be compatible with the same compiler. Sometimes there are compiler bugs that affect some projects, and sometimes projects contain code errors that certain compilers won't allow. We need the freedom to be able to impose compiler blacklist on a port by port basis. Fortunately, you already have the wxWidgets-1.0 portgroup, which all ports which use wxWidgets are supposed to use, so you could impose any needed blacklisting there, but that won't help you if the compiler choice needs to be imposed on perl ports as well. I'm not clear why that would be needed though. What kind of errors do you see when you try to mix compilers? > What's the proper blacklisting? Since llvm-gcc-4.2 seems to work fine, > I'm tempted to blacklist llvm-gcc just on Lion and newer, while > letting 10.6 build with its default compiler (llvm-gcc). I didn't test > 10.6 yet though. Is that too weird? Does anyone have a better > suggestion? So wait, llvm-gcc-4.2 works, but gcc-4.2 does not? I guess that's possible, it's just unexpected; llvm-gcc-4.2 is supposed to be a gcc-4.2-compatible front end for the llvm backend. > Meanwhile I need to debug some weird side effects, like p5-wx trying > to compile with > /opt/local/clang++ -stdlib=libc++-mp-3.4 > for example. I didn't ask it to do anything like that. Yeah that looks wrong! I wonder why it's doing that. On Nov 1, 2017, at 12:37, Ken Cunningham wrote: > I know it's not the party line, but IMHO to minimize hassles supporting these > older systems we might well just flush them all to build everything with > clang-4.0 or 5.0, to match the newer systems. Then most all systems would see > similar or identical errors. > > I'm not too clear on why it's worth effort to do otherwise. We can entertain all reasonable options. I can read your suggestion two different ways: a) Use clang-4.0 or 5.0 on Mountain Lion and earlier with libstdc++; or b) Use clang-4.0 or 5.0 on Mountain Lion and earlier and require them to switch to libc++ [1]. What immediately springs to mind for me for (a) (use libstdc++) is an uncertain bootstrapping process -- how do you get to the point of having clang-4.0 or 5.0 installed so that you can then compile other ports with it? llvm-3.4 is the last version that does not require C++11. So it's the last version that can build using libstdc++. llvm-3.5 and later build using /usr/lib/libc++.dylib. This is present as part of OS X on Lion and later. On Snow Leopard and Leopard, it's provided by the libcxx port. It's not available for Tiger. I'm not certain how usable it is on Leopard on Intel since support for libc++ on Leopard was just added one year ago. As you know, clang doesn't really work on PowerPC yet. If you take the view that we should drop PowerPC support, then we should drop support for Leopard as well. Leopard support is only important for PowerPC users. All Leopard-capable Intel Macs can and should be upgraded to Snow Leopard. llvm-3.7 is the last version that can build using clang-3.4 or earlier, so llvm-3.8 and later cannot be built using any compiler available on a standard Snow Leopard system. (When I run "port info llvm-3.8" on Snow Leopard, it says all compilers are blacklisted.) Perhaps llvm-3.8 or later could be built using clang-3.7 if it were added to the compiler fallback list. If I look at the recursive dependencies of libcxx and clang-5.0 on a standard Snow Leopard system, I see 61 ports, including 6 different versions of clang. Granted that list may be inaccurately large due to MacPorts' assertion that all compilers are blacklisted; it's possible that by carefully adding some compiler fallbacks to the newer llvm ports, we could reduce the number of older clangs that need to be installed to get there. Bear in mind that all the dependencies of all of the clangs we end up installing would need to build using older compilers, since they are prerequisites for the newer compilers. Are we sure that one of those ports isn't now (or won't in the future be) in the dependency chain of a port that uses wxWidgets? Possibly the list of dependencies could be reduced by having a bootstrap compiler, like we do today on Tiger. On Tiger, we begin by installing the apple-gcc42 port with the bootstrap variant, which makes a compiler with a minimal set of features and dependencies, and then we instruct the user to rebuild apple-gcc42 without the bootstrap variant to get the full featureset. We could improve on that by having an apple-gcc42-bootstrap subport instead; then no manual reinstallation would be needed. We might be able to do something similar for one or more clang ports. If you meant (b) (use libc++), then we know the bootstrapping process [1] but it takes a bit of work for the user to do, and we still need to settle the matter of the package naming convention so that we can start building binaries for this configuration. [1] https://trac.macports.org/wiki/LibcxxOnOlderSystems
