Re: [Swig-devel] OSX test build failures using clang

[William S F. <ws...@fu...>]

On 23/01/14 16:20, Clemens Lang wrote:
> On Thu, Jan 23, 2014 at 10:50:10AM -0500, Marvin Greenberg wrote:
>> If swig plans to only support development on OSX using gcc (as it does
>> on windows with mingw gcc), probably it should be mentioned in the
>> documentation.
>
> I'd like to chime in on this and say that supporting only GCC for C++
> code on OS X really isn't an option anymore.
If I've misled anyone, I apologise. clang on OSX is clearly the future 
direction and would be the best compiler to test in the long run.

In the past, next to no OSX testing was done and now I'm trying to ramp 
it up. Until Travis brought out their Mac platform there wasn't any way 
to test OSX -- no-one seemed to have a machine to do it. This wasn't 
that awful as gcc was the compiler and gcc was well tested on other 
platforms. Not ideal, but we didn't get many OSX specific bug reports. 
Now with the easy ability of testing OSX on Travis, we should. Testing 
either gcc or clang is quite easy too. I envisage testing both.

> The latest OS X release
> switched the default C++ runtime library to clang's libc++ instead of
> GCC's libstdc++ (that was kept at the version equivalent to GCC 4.2 in
> OS X for licensing reasons and thus doesn't support C++11).
>
> Mixing the two C++ runtime libraries in a process (e.g. by linking
> software compiled with GCC or against libstdc++ to software compiled
> against libc++) leads to crashes at best. Since the default runtime
> library switched, all libraries installed by the OS and using
> third-party package managers such as Homebrew and MacPorts[sic!] will
> use libc++.
>
> If SWIG insists on GCC, that means the code generated by SWIG will be
> incompatible with any of these libraries, leading to great user
> frustration (e.g., if the software crashes or doesn't compile due to
> different symbol mangling). The only solution to the problem would be to
> recompile *all* C++ dependencies a software needs against the same
> standard library, and I doubt anybody would want to do that.
>
There are two things here. The SWIG executable compiles cleanly and 
seems to run fine using clang on OSX. Testing the generated wrappers is 
much harder as somehow we need to know what dependencies the target 
languages are compiled with so that the wrappers can be compiled the 
same way. That is usually some fun for SWIG users to wrestle with. But 
now that there is an opportunity to test on Travis, these problems come 
closer and a SWIG developer needs to solve them too in order to get the 
Travis tests working.

> My experience as MacPorts Developer suggests that most users don't get
> what problems might be caused by mixing the runtimes and tend to do "it
> compiles, ship it" as quality assurance, which unfortunately often isn't
> enough to catch the problems that might arise.
>
Disclaimer: I really am not very familiar with OSX! I have managed to 
use homebrew, but macports is completely foreign to me. I've gone down 
the gcc route on Travis initially as it seemed to work reasonably well 
on Mountain Lion when Travis was using it but clang on Mavericks seemed 
immature. I have seen some of those C++ runtime library runtime bugs you 
mention even with gcc on Mountain Lion. Probably it is just some linker 
settings to sort out, but I havn't delved into it and would need someone 
with an apple mac to take a look.

What I can do is set up a Travis branch to which we can merge regularly 
for OSX Travis testing. I'll let you all know when done. I don't think 
there is much work to be done to get the tests working on OSX by someone 
experienced on the platform and the good thing is once they are working, 
it is usually quite easy to keep them working. In order to do testing on 
the two Travis operating systems, we need two branches as we need to 
have two different .travis.yml files. Has anyone come across a way for 
Github to automatically merge to another branch when commits are made on 
master?

William