boost link error

[TurBoss]

Hi

I'm having problems when linking to boost AR already set to "x86_64-apple-darwin15-ar"

I have been told that boost is compiled with clang and incompatible with gcc but can be recompiled using macports

sudo port -ns upgrade --force boost configure.compiler=macports-gcc-4.9

is posible to do this with osxcross-macports?

Thanks

[tpoechtrager]

What's the exact linker error you are getting?

[TurBoss]

hello: here is the output

http://dpaste.com/2E2TGB0

sorry not sure if a linker error or what

[tpoechtrager]

I think this is caused by the different C++ standard library (libstdc++ vs. libc++). Building with Clang is not an option?

[TurBoss]

Sorry but no.

This is a online game, clang builds does not sync the online players

[tpoechtrager]

@jtv who had a similar problem once, wrote me the following via e-mail (he can't login on GitHub at the moment):

All I can say is: the errors do sound like link errors. Many compile-time problems could cause them:

• As you say, could be different standard library implementations. I'm not sure now that I can't see the errors but I think it's not that; IIRC the missing functions were in Boost, not in the standard library.
• Building with C++11 (or later) but linking with a library built against an older version of C++. Or vice versa.
• Enabling runtime debug error checking on one side of the link, but disabling it on the other.
• Forgetting to link a library, or linking in the wrong order (duh).

However I hit some additional problems myself when working with Boost.

One: The Boost build has no way to use non-native ar & ranlib when building with clang. It just quietly uses the native versions, which seem to work, but quietly break your library!

With gcc there is a way to select your ar and ranlib in the Boost build, but you have to configure this explicitly when cross-compiling with OSXCross. The same config is accepted when building with clang, but doesn't actually do anything.

A trick that will work either way: link or copy the two osxcross versions of the tools into a temporary directory, under the names "ran" and "ranlib" (no added qualifiers, just exactly those names!) and add that directory to the front of your PATH when building Boost. The Boost build doesn't use full paths when calling these tools, so this way it calls the OSXCross versions instead of the native versions.

Two: The default linker configuration was a problem when building with clang. I got around that by patching a bjam config file... Could dig that up another time, but in this case it may not be needed.

Three: Throwing/catching exceptions crashed. I eventually solved that by using clang instead of gcc... I don't think I ever resolved the real problem.

Jeroen

---

Sorry but no.

This is a online game, clang builds does not sync the online players

Why would a Clang build not "sync the online players"?

[TurBoss]

Why would a Clang build not "sync the online players"?

sync is determinated by a hash over the whole gamefiles and gamestate obviously the binary built by clang is diffrent from the gcc

:)

[tpoechtrager]

You wouldn't get a "matching" binary with GCC either....

[TurBoss]

Windows and linux syncs,

and the windows build is using the mxe wich is similar to osxcross

well i don't know

Thanks any way

[tpoechtrager]

Your hashing code might be broken then. You really should be using Clang on/for Mac OS (X).

[TurBoss]

i will point the dev team to this issue maybe they have a better idea of whats goin on

Thanks

[abma]

Your hashing code might be broken then. You really should be using Clang on/for Mac OS (X).

"sync" in the context of spring means that all fpu operations needs to calculate the same results. for some reasons this fails with clang, so gcc must be used. Its not about hashing which usually uses integer operations.

this issue imo should be reopened.

[tpoechtrager]

I can't help any further than what @jtv did with his e-mail. "For some reason" might mean undefined behavior.

[abma]

the description of this issue is inappropriate:

for the spring engine to correctly work it must be compiled with gcc. clang is incompatible / can't be fixed easily. To make spring compile correctly boost must be compiled with the same compiler as well, so its a feature request that osxcross compiles boost using the cross-gcc.

idk whats the exact problem with (re)compiling boost inside an osxcross environment or if there is a problem at all.

[abma]

maybe more details: http://nicolas.brodu.net/en/programmation/streflop/ (spring uses streflop)

[OmniBlade]

Are you compiling for SSE2 with GCC? Its possible that without that it is compiling for the older x87 fpu which can give slightly different results if clang is compiling to SSE2 code. There are loads of minor things that can change the floating point results, there are flags for the compiler that let it re-order some equations which you might want to disable as well.

[abma]

no, only SSE is used:

https://github.com/spring/spring/blob/develop/rts/build/cmake/TestCXXFlags.cmake#L64

[OmniBlade]

Check the value of FLT_EVAL_METHOD macro found in float.h when building with GCC and Clang and ensure they match. I have read that GCC needs SSE2 set to consistently produce SSE instructions rather than falling back to the fpu in some versions.