News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Unable to compile Extended in Arch's MinGW cross-compilation toolchain

Started by Roboron, February 07, 2022, 12:58:12 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Roboron

Note 1: My system is setup to compile Standard with MinGW, and I do that frequently, so it is not a miss-configuration on my part, but something that differs in Extended.
Note 2: This is not a recent bug, I probably noticed it a year ago, but it doesn't have priority for me.

When compiling Simutrans Extended, I get the following errors in the linking phase.

CMakeFiles/simutrans-extended.dir/objects.a(brueckenbauer.cc.obj):brueckenbauer.cc:(.text+0x599e): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for karte_t::marker_index'
CMakeFiles/simutrans-extended.dir/objects.a(brueckenbauer.cc.obj):brueckenbauer.cc:(.text+0x59bb): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for karte_t::marker_index'
CMakeFiles/simutrans-extended.dir/objects.a(tunnelbauer.cc.obj):tunnelbauer.cc:(.text+0x3cd3): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for karte_t::marker_index'
CMakeFiles/simutrans-extended.dir/objects.a(tunnelbauer.cc.obj):tunnelbauer.cc:(.text+0x3cf5): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for karte_t::marker_index'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x72b4): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for route_t::MAX_STEP'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x72f6): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for karte_t::marker_index'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x7300): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for karte_t::marker_index'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x7311): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for route_t::max_used_steps'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x744c): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for route_t::max_used_steps'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x7466): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol `TLS init function for route_t::max_used_steps'
CMakeFiles/simutrans-extended.dir/objects.a(wegbauer.cc.obj):wegbauer.cc:(.text+0x76aa): additional relocation overflows omitted from the output


After some investigation, I discovered a solution in this related post, which involves adding  "-Wl,--image-base,0x10000000" to the linker flags (I have no idea of what this does).

=> https://bitbucket.org/berkeleylab/upcxx/issues/58/regression-on-cygwin-opt-undefined-symbol

However, it has an unintended side effect: It disables static compilation, which was otherwise working perfectly...

As mentioned, this issue doesn't really bother me much, because I don't have the need to cross-compile Extended myself. But according to the previous post, it may be caused by non-portable code, and that is probably desirable to avoid, so I am reporting it in case you want to take a look.

prissi

According to the text it is due to accessing thread_local variable using extern. But the offended variable are actually static.

Looking at the actual code, I wonder how a variable, which is initialised by each thread inidvidually (because static thread_local marker_index) can be used to index a thread like in wegbauer.cc

marker_t& marker = marker_t::instance(welt->get_size().x, welt->get_size().y, karte_t::marker_index);

Wouldn' that return always the same number on each thread? But then my knowledge of threads is almost non-existent.