Open Gastove opened 4 years ago
Having manually shifted the files about, I'm also running in to this point, where the build just hangs:
------------- Extempore --------------
Andrew Sorensen (c) 2010-2020
andrew@moso.com.au, @digego
ARCH : x86_64-unknown-linux-gnu
CPU : broadwell
ATTRS : -sse4a,-avx512bw,+cx16,-tbm,+xsave,-fma4,-avx512vl,+prfchw,+bmi2,+adx,+xsavec,+fsgsbase,+avx,-avx512cd,-avx512pf,-rtm,+popcnt,+fma,+bmi,+aes,+rdrnd,+xsaves,+sse4.1,+sse4.2,+avx2,-avx512er,+sse,+lzcnt,+pclmul,-avx512f,+f16c,+ssse3,+mmx,-pku,+cmov,-xop,+rdseed,+movbe,-hle,+xsaveopt,-sha,+sse2,+sse3,-avx512dq
LLVM : 3.8.0 MCJIT
Primary : thread 0
---------------------------------------
INFO: starting utility process...
INFO: server: accepted new connection to utility process
INFO: client: connected to server utility process at localhost:17072
INFO: starting primary process...
INFO: server: accepted new connection to primary process
INFO: client: connected to server primary process at localhost:17073
Evaluating expression: (impc:aot:compile-xtm-file "libs/external/gl/glcore-directbind.xtm")
INFO: started compiling libs/external/gl/glcore-directbind.xtm
Loading xtmbase library... done in 0.724026 seconds
sys:load notification base already loaded
Error: could not find libGL dynamic library
Hey there, yep, the CMake build stuff is... complicated. Especially across Linux distros, it seems. The "missing libGL" error is related to this (although the workaround in this case is to just build with -DEXTERNAL_SHLIBS_GRAPHICS=OFF
).
The way to fix it properly is to change the stuff around CMakeLists.txt:713
so that instead of hardcoding the name of the so files it uses variables from the CMake build process for each dep (e.g. libsndfile), returned from the relevant "External Project" CMake build step to get the actual name of the so files. However, there's no standard way of doing this, so it'd be a matter of looking at the CMakeLists.txt
for each of those deps and figuring out the name of the relevant variable, then using that in Extempore's CMakeLists.txt
. In addition, there might be some "scoping" issues because they're built through ExternalProject_add
rather than directly---I don't fully understand all the nuances of that process.
Of course, there might be a nicer way to do this; I know a bit of CMake (and wrote Extempore's build system stuff) but I'm far from a guru.
The good news, though, is that at least we have a CI pipeline these days so it's easier to make sure any changes you've made haven't broken things on other platforms.
I am running into this same problem on NixOS. Thank you for making this issue. It is helpful ;)
I'm working on building extempore on Fedora 32; I'm running into an issue in which it seems a set of files are being built correctly, but are not being moved to the correct staging directory.
The files in question are
librtmidi.so
andlibsndfile.so
. I hit problems withlibrtmidi.so
first:Line 81 of
external_shlibs_audio.dir/build.make
is attempting to run:Surely enough,
librtmidi.so
is not in the source directory:But it has been built! I can symlink it myself:
Which gets me the same problem in a slightly different version:
I am really not good at cmake; this feels like something is missing either a flag or a copy step to get everything in the correct place. I'd be happy to PR it, with a little guidance on where to start digging.
Any advice?