On Wed, Aug 28, 2013, at 06:06 PM, Jeremy Huddleston Sequoia wrote: > On Aug 28, 2013, at 13:19, Michael Dickens <michae...@macports.org> > wrote: > > > I tried setting all of the relevant binaries to use > > /usr/lib/libstdc++.6.dylib, then "make test" failed with the same result > > ... > > So, there are differences. Hmmm .... probably just not backward > > compatible, which is not a big surprise. > > No, libstdc++ *is* backwards compatible (MP's libstdc++ can be used as a > replacement for the host's). libstdc++ is not *forward* compatible (the > host's libstdc++ cannot be used as a replacement for MP's).
What you wrote is what I meant to write. Maybe I did not succeed? Moving from MacPorts' libstdc++ (which is newer) -back- to Apple's libstdc++ (which is older) did not work; hence, no backwards compatibility from newer to older. > > Recompiling using "configure.compiler=macports-gcc-4.7" is supported; > > No, it *may work*, but it is not supported (a ticket filed will be closed > as invalid) ... just like MacPorts *may work* on Leopard and Tiger, but > it's not supported. Ah; OK; well then. So MacPorts -officially- supports just whatever compiles Apple provides for the given OS. MacPorts' GCC, Clang, LLVM, and so forth are not officially supported, and may or not work. I'm glad that's clarified (at least with me); I thought that in ports that provided variants for +gcc4X, the MacPorts' GCC was actually supported. > > all MacPorts ports > > using C++ use the MacPorts-provided libstdc++, no matter the > > configure.compiler setting. > > Choosing libstdc++ would force us to abandon Apple's compiler, and I (and > I'm sure many others) would have to choose to either fork or stop using > MacPorts. > > If we're going to choose to migrate to a different C++ runtime, it will > be the host's libc++, not MP's libstdc++. Snow Leopard users can get a > "host" libc++ from the libcxx port. My thought is to do an internal post-destroot that looks over all of the files, and for those that are binaries (libraries, executables) it checks for Apple's libstdc++ and if found does an "install_name_tool -change" to use MacPorts' version instead. This solution should be relatively simple to implement, and, as you wrote above (and, I think we are in agreement on) MacPorts' libstdc++ can be used to replace Apple's libstdc++ (just not the other way around). We'd need to add a post-install hook for "port" for existing installations, but that should also be relatively simple to implement. I'm not saying I'm 100% thinking this is the right way to go, but it is an interesting idea that might be worth testing to see if it really works -- and, potentially a short-term solution to this whole "which c++ library do we use?" issue while a better long-term solution is determined. In this manner, any compiler can be used. > I'm not sure what you mean by "all assembly is GCC-style" ... perhaps you > mean it's not darwin compatible, but AFAIK, there is no "GCC-style" for > assembly. Please point me to what you are referring to. Whatever assembly the GR programmers hand-coded, they made sure it works with GCC; not clang or any other compiler. I do not know if there is such a thing as "GCC-style" but it sounded good; maybe all assembly these days is cross compiler compatible? In my programming experience over the last 30+ years, assembly language programming is very compiler specific; so, I highly doubt that assembly written with GCC in mind compiles cleanly using clang -- though I'd love to be proven wrong. This is not to say that it's not possible to write assembly for both GCC and clang, but rather that, in general, if one tests with GCC only, then the resulting code is likely to not compile cleanly for other compilers. > > Can you expound on "afraid of GPL3 cooties"? I'm curious what you're > > getting at. - MLD > > I cannot taint myself by reading GPLv3 code. It makes triaging issues > with gcc "interesting"... That doesn't help (me) very much. I read and use GPL (v2, v3) code daily, and I don't feel like I'm tainted. While the GPL is meant to be hyper-viral (anything that touches that code becomes GPL'd to the same degree), the reality is that folks (like me) read through such code regularly, get great ideas, and then write their own code to replicate the idea with augmentation. In this manner, the original GPL'd code was never copied or used verbatim, and hence has no jurisdiction. The (US) courts are also undecided on how viral the GPL is; so, there's room for interpretation and leniency/forgiveness. Further, GCC's license provides an exception to the GPL such that the programmer can assign his/her own license to both the source and binary code for a project; it allows alternative compilers used in conjunction with GCC, and alternative linkers and assemblers; it is quite lenient, basically not permitting non-GPL'd plugins (or, that's how I read it). So, assigning priority for issues relating to GCC should be the same as any other prioritization (unless you're actually modifying GCC code). Or am I mis-understanding what you wrote? - MLD _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
