ldc-developers / ldc2.snap

Snap package definition for LDC, the LLVM-based D compiler
11 stars 4 forks source link

Re-enable MULTILIB support for the LDC build #51

Closed WebDrake closed 6 years ago

WebDrake commented 6 years ago

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, and lib64 for 64-bit libraries in a 32-bit build.

WebDrake commented 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).

dnadlinger commented 6 years ago

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.

WebDrake commented 6 years ago

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?

kinke commented 6 years ago

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.

WebDrake commented 6 years ago

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.

WebDrake commented 6 years ago

This seems to be working locally now. Let's give it a go in the launchpad build system.