Closed WebDrake closed 6 years ago
Unfortunately, this is failing when I try to build it locally:
[ 84%] Linking C shared library ../lib32/libphobos2-ldc-shared.so
cd /media/joseph/hexxat/code/snap/ldc2.snap/parts/ldc/build/runtime && /usr/bin/cmake -E cmake_link_script CMakeFiles/phobos2-ldc-shared_32.dir/link.txt --verbose=1
/usr/bin/cc -fPIC -DHAVE_UNISTD_H -O3 -DNDEBUG -Wa,-mrelax-relocations=no -m32 -shared -Wl,-soname,libphobos2-ldc-shared.so.79 -o ../lib32/libphobos2-ldc-shared.so.2.0.79 ............ ../lib32/libdruntime-ldc-shared.so.2.0.79 -lm -lpthread -lrt -ldl -Wl,-rpath,/media/joseph/hexxat/code/snap/ldc2.snap/parts/ldc/build/lib32:
objects_32/std/format.o: file not recognised: File truncated
collect2: error: ld returned 1 exit status
runtime/CMakeFiles/phobos2-ldc-shared_32.dir/build.make:1943: recipe for target 'lib32/libphobos2-ldc-shared.so.2.0.79' failed
make[2]: *** [lib32/libphobos2-ldc-shared.so.2.0.79] Error 1
... any thoughts on why, anyone? This is the first time I've encountered a problem doing a multilib build on a 64-bit system (the only problems before were on 32-bit).
I've only ever seen "File truncated" when make dependencies were missing and the compiler was still writing the object file, or when the latter crashed but left behind an already created object file.
Things build fine with this patch if I apply it on top of the 1.8 package, but fails if I include the BUILD_LTO_LIBS
change. So there appears to be some kind of clash between these two things.
That doesn't seem to be an issue for the CircleCI builds, so is there something I'm missing in the build setup?
I've also seen these File truncated
issues, but not recently. They were mostly due to parallel building of the same object files IIRC, sporadically leading to conflicts and according errors; that was particularly so when making the static and shared Phobos libs depend on the same object files (PIC in both cases, so only compiled once), and those are created via CMake custom commands. I think the workaround was to switch from make to ninja, which seems to handle these dependencies properly. IIRC, I quickly looked into it and make seems to handle these custom-command dependencies by scanning the file system for missing object files, and doing this scan separately and independently per static/shared Phobos library rule, so there's a race condition if both rules are processed simultaneously.
I've also seen these File truncated issues, but not recently. They were mostly due to parallel building of the same object files IIRC, sporadically leading to conflicts and according errors
I've had such an issue show up in the build of the most recent 1.9 version of the snap package, where BUILD_LTO_LIBS
was introduced:
https://code.launchpad.net/~ldc-developers/+snap/ldc2-1.9/+build/236199
That suggests its occurrence may be independent of the introduction of multilib.
that was particularly so when making the static and shared Phobos libs depend on the same object files (PIC in both cases, so only compiled once), and those are created via CMake custom commands
Could it be that because the BUILD_LTO_LIBS
addition causes additional libraries to be built, and multilib adds even more, that it's increasing the likelihood that this issue shows up?
I think the workaround was to switch from make to ninja, which seems to handle these dependencies properly.
This would be the ninja-build
package on Ubuntu, right? I'll give that a go.
This seems to be working locally now. Let's give it a go in the launchpad build system.
This should ensure that both 32- and 64-bit libraries are available in the snap package, whatever the target architecture of the build. With various issues addressed since the last time we tried this, it seems worth repeating the attempt.
ldc2.conf
has been updated to handle all possible expected library paths:lib
for native,lib32
for 32-bit libraries in a 64-bit build, andlib64
for 64-bit libraries in a 32-bit build.