SDK 3.2: linker failure (regression)

[karry]

REPRODUCIBILITY: always
BUILD ID: SDK 3.2
HARDWARE: build engine, Virtualbox
REGRESSION: yes

DESCRIPTION:

After upgrading SDK to recent version (3.2) my C++ application fails to compile (OSM Scout: https://github.com/Karry/osmscout-sailfish). It fails while linking binaries:

/usr/bin/c++  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -fmessage-length=0 -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb -Wno-psabi -fopenmp -O2 -g     -pie CMakeFiles/Routing.dir/dependencies/libosmscout/Demos/src/Routing.cpp.o CMakeFiles/Routing.dir/Routing_autogen/mocs_compilation.cpp.o  -o Routing dependencies/libosmscout/libosmscout/libosmscout.a libmarisa.a -lc 
/srv/mer/toolings/SailfishOS-3.3.0.16//opt/cross/bin/armv7hl-meego-linux-gnueabi-ld: dependencies/libosmscout/libosmscout/libosmscout.a(TypeInfoSet.cpp.o): bad reloc symbol index (0x233f0c >= 0x82) for offset 0xf8 in section `.text._ZNSt6vectorISt10shared_ptrIN8osmscout8TypeInfoEESaIS3_EED2Ev[_ZNSt6vectorISt10shared_ptrIN8osmscout8TypeInfoEESaIS3_EED5Ev]'
/srv/mer/toolings/SailfishOS-3.3.0.16//opt/cross/bin/armv7hl-meego-linux-gnueabi-ld: dependencies/libosmscout/libosmscout/libosmscout.a: error adding symbols: bad value
collect2: error: ld returned 1 exit status

It fails even when I cleanup build directory before build. It is possible that I have some error in my CMake, but it fails even with v2.4 tag, that was build without issue in previous SDK release.

STEPS TO REPRODUCE:

# install recent SDK to default location

OS_VERSION=3.3.0.16
sfdk config target=SailfishOS-${OS_VERSION}-armv7hl

# HACK: gcc libs like libgomp.so are missing under the build target
sfdk engine exec sudo cp \
    /srv/mer/toolings/SailfishOS-${OS_VERSION}/opt/cross/armv7hl-meego-linux-gnueabi/lib/libgomp.so.1.0.0 \
    /srv/mer/targets/SailfishOS-${OS_VERSION}-armv7hl/usr/lib/libgomp.so.1
sfdk engine exec sudo cp \
    /srv/mer/toolings/SailfishOS-${OS_VERSION}/usr/lib/libgomp.so.1.0.0 \
    /srv/mer/targets/SailfishOS-${OS_VERSION}-i486/usr/lib/libgomp.so.1

git clone --recursive https://github.com/Karry/osmscout-sailfish
cd osmscout-sailfish
sfdk build

EXPECTED RESULT:

get osmscout package

ACTUAL RESULT:

linking fails

[martyone]

@karry I updated your report to use more convenient commands Is the workaround you mentioned complete? The build still fails for me after applying it. Tried just the armv7hl part, didn’t investigate further yet.

[karry]

Thanks I am using my scripts from early SDK versions, when sfdk was not there…

The “HACK” in howto solves different issue (libgomp.so.1 is not visible in target). It is unrelated with this new linking issue.

[karry]

I was able to recover ~/SailfishOS/vmshare and ~/SailfishOS/mersdk directories from one week old backup. Now I can 100% confirm that recent master of OSM Scout is buildable with previous version of SDK and I am able to do experiments in both versions…

The issue seems to be similar to this one:
https://bug-binutils.gnu.narkive.com/WXEOToHz/question-about-invalid-string-offset-could-not-read-symbols-malformed-archive-linker-errors

cd rpmbuilddir-arm.sdk3.2/

$ find . -name \*.a -exec arm-linux-gnueabihf-objdump -p {} \; > /dev/null
arm-linux-gnueabihf-objdump: warning: ./libmarisa.a(agent.cc.o) has a corrupt section with a size (8aabfe9d) larger than the file size
arm-linux-gnueabihf-objdump: warning: ./libmarisa.a(agent.cc.o) has a corrupt section with a size (35cd2d57) larger than the file size
arm-linux-gnueabihf-objdump: warning: ./libmarisa.a(agent.cc.o) has a corrupt section with a size (8aabfe9d) larger than the file size
arm-linux-gnueabihf-objdump: warning: ./libmarisa.a(agent.cc.o) has a corrupt section with a size (35cd2d57) larger than the file size
arm-linux-gnueabihf-objdump: agent.cc.o: file format not recognized

mkdir -p tmp
cd tmp

$ unar ../libmarisa.a 
../libmarisa.a: Ar
  reader.cc.o  (77536 B)... OK.
  mapper.cc.o  (32084 B)... OK.
  writer.cc.o  (77944 B)... OK.
  tail.cc.o  (270372 B)... OK.
  louds-trie.cc.o  (823868 B)... OK.
  bit-vector.cc.o  (99532 B)... OK.
  trie.cc.o  (141520 B)... OK.
  agent.cc.o  (97756 B)... OK.
  keyset.cc.o  (52676 B)... OK.
Successfully extracted to "libmarisa".

$ arm-linux-gnueabihf-objdump -p libmarisa/agent.cc.o 
arm-linux-gnueabihf-objdump: warning: libmarisa/agent.cc.o has a corrupt section with a size (8aabfe9d) larger than the file size
arm-linux-gnueabihf-objdump: warning: libmarisa/agent.cc.o has a corrupt section with a size (35cd2d57) larger than the file size
arm-linux-gnueabihf-objdump: warning: libmarisa/agent.cc.o has a corrupt section with a size (8aabfe9d) larger than the file size
arm-linux-gnueabihf-objdump: warning: libmarisa/agent.cc.o has a corrupt section with a size (35cd2d57) larger than the file size
arm-linux-gnueabihf-objdump: libmarisa/agent.cc.o: file format not recognized

$ arm-linux-gnueabihf-objdump -p ../CMakeFiles/marisa.dir/dependencies/marisa-trie/lib/marisa/agent.cc.o
../CMakeFiles/marisa.dir/dependencies/marisa-trie/lib/marisa/agent.cc.o:     file format elf32-littlearm
private flags = 5000000: [Version5 EABI]

$ file libmarisa/agent.cc.o 
... /agent.cc.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped

$ file ../CMakeFiles/marisa.dir/dependencies/marisa-trie/lib/marisa/agent.cc.o
... /agent.cc.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped

It seems that object file is malformed by ar or ranlib tool during “linking” static library archive. But both SDKs seems to use same ar and ranlib binaries (GNU Binutils 2.32).

[martyone]

Found the issue. You can work it around with:

touch ~/SailfishOS/vmshare/home-mersdk-share.no-dynexec
touch ~/SailfishOS/vmshare/home-src1.no-dynexec

Restart the build engine to see the effect.

[karry]

Thank you. It really helps. Can you explain what is behind this black magic?

[martyone]

VirtualBox’s file sharing mechanism does not transfer file permissions. All shared files are 0644 inside the build engine. This makes it impossible to use the SDK to build packages that need to execute something from their source/build directory at build time. This applies e.g. to Autotools-based packages. SDK 3.2 newly utilizes a thin overlay file system, which marks files as executable when they look so, as a means to deal with this limitation of VirtualBox. And this breaks your build for some reason. The respective services can be disabled by creating the afforementioned *.no-dynexec files.

[karry]

So, it really is workaround, not the solution

[karry]

I just tried to reinstall SDK and select Docker-based build endine. It seems that this problem is not there and is affecting just Virtualbox build engine…

[martyone]

Yes, but only on Linux. On Windows the Docker-based build engine is affected as well.