bits/c++config.h: No such file or directory about xgo HOT 6 CLOSED

Hey, sorry about not replying earlier. Didn't have time to work on xgo.

The issue was basically that xgo was not set up until now to cross compile C++, meaning that none of the required C++ headers, libraries or toolchains were present. I've been hacking a bit on the project in the last week or so, and I'm happy to say I managed to get this aspect covered too, so now your project compiles successfully to Linux and Windows:

$ xgo --targets=linux/*,windows/* github.com/wellington/wellington/wt

OSX fails with some missing standard library component error. I'm not entirely sure where this error comes from. It may simply be caused by an old SDK or some other error. I'll have to dig deeper into it.

In file included from ../../go-libsass/libs/unity.cpp:2:
In file included from ../../go-libsass/libs/../libsass-build/ast.cpp:1:
../libsass-build/ast.hpp:12:10: fatal error: 'unordered_map' file not found

The other missing platform that I cannot get your code built is Android (late addition to the xgo flock), due to the following error:

../../go-libsass/libs/../libsass-build/util.cpp:31:38: error: 'struct lconv' has no member named 'decimal_point'
     char separator = *(localeconv()->decimal_point);

According to a stack overflow question, this is caused by the Android NDK having a limited locale.h header, that is missing a few things. So this should be corrected on your side.

PS: docker is still crunching through the updates, so it will take a half an hour until the updates are downloadable.

from xgo.

Oh hey awesome, thanks for taking the time to build against my project. Looking online the unordered map error could be fixed by adding stdlib=libc++. I may just need to add that to my cgo instructions. Odd that I build fine locally on OS X.

from xgo.

Hmm, I think the issue is that xgo uses the OSX 10.6 SDK, which contains tr1/unordered_map, which was moved to simply unordered_map in a later SDK. However I'm not entirely sure what the correct fix for xgo is. I could include a newer SDK, but that would break all binaries on older platforms, so it's not really advisable. Maybe for now I'd suggest dependent code to include a C++ macro to check whether the tr1 or the new version should be included.

from xgo.

That does sound like the culprit. OS X 10.6 is very old and takes a lot of header sniffing to detect differences from modern OS X. I'm not aware of a way to test for existence of a header in cgo. The upstream C project uses autotools to detect for the correct header and set it. Not an elegant solution for a go project unfortunately.

from xgo.

I've been searching a bit around for whether or not Go 1.5 still supports OS X 10.6 as there's only one version on the download page, and according to this issue golang/go#9511, 1.5 is the last officially supporting release, with 1.6 simply not maintaining it any more.

Now, the interesting question really is what xgo should do in this respect. The best theoretical solution would be to use the old 10.6 SDK's when building with anything below Go 1.5, and to switch over to the 10.8 SDK (or whatever version) above it. The problem is that all cross compilation tools are in the base image, and only the Go distribution changes above it based on the version requested, so to support two different SDKs, it would mean creating multiple base images, which will become a maintenance nightmare.

I think that for now, I'll leave it as is as I don't have the time to do a full OSX rework, and when Go 1.6 arrives, I'll replace the old SDK with 10.8. Hopefully not many people will have issues with it until then.

from xgo.

Sounds good! I'll just keep using my windows and Linux CIs to create
binaries. Glad to see there's some helpful tools for cgo projects. Thanks a
lot for working on this.

On Sat, Sep 19, 2015, 10:09 AM Péter Szilágyi [email protected]
wrote:

I've been searching a bit around for whether or not Go 1.5 still supports
OS X 10.6 as there's only one version on the download page, and according
to this issue golang/go#9511 golang/go#9511,
1.5 is the last officially supporting release, with 1.6 simply not
maintaining it any more.

Now, the interesting question really is what xgo should do in this
respect. The best theoretical solution would be to use the old 10.6 SDK's
when building with anything below Go 1.5, and to switch over to the 10.8
SDK (or whatever version) above it. The problem is that all cross
compilation tools are in the base image, and only the Go distribution
changes above it based on the version requested, so to support two
different SDKs, it would mean creating multiple base images, which will
become a maintenance nightmare.

I think that for now, I'll leave it as is as I don't have the time to do a
full OSX rework, and when Go 1.6 arrives, I'll replace the old SDK with
10.8. Hopefully not many people will have issues with it until then.

—
Reply to this email directly or view it on GitHub
#18 (comment).

from xgo.