#40 Make check fails on OSX

[Matt Denwood]

Running make check on beta2 fails on OS X 10.9.5 with the following:

ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '../src/modules/glm/.libs/glm.so' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: [modules] Error 1
make[1]: [check-am] Error 2
make: *** [check-recursive] Error 1

[Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)]

I have tried adding a -dynamiclib compiler and -dylib ld flag, but just get a note from the compiler that it is being ignored. Any ideas?

[Matt Denwood]

I have spent the afternoon investiagting this further. The error seems to change randomly between src/modules/glm/.libs/glm.so and src/modules/bugs/.libs/bugs.so but otool -hv reports both being bundles rather than dylibs - eg:

bugs.so:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL 0x00 BUNDLE 18 2136 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK

Running otool -L confirms that the shared libraries it uses are all dylibs - hence the issue.

I can see that -dynamic is passed to ld, and have also tried -dynamiclib to clang and -dynlib to ld but get the same error (and it seems to break the install anyway). At this point I'm not sure where the problem is, but candidates are the -framework Accelerate I am using to find Apple's blas+lapack (but I get the same error using -isysroot for the same job), Apple's ld/clang implementation, or something in the make check procedure or cppunit linker step. The machine I have with me today is 10.9.x so I am stuck with Xcode+llvm 6.0 here, but I will try with Xcode+llvm 7.0 on my other machine tomorrow.

On the one hand, running make (install) works perfectly, which suggests a problem with cppunit/make. On the other hand, the glm.so and bugs.so binaries seem to be built by make not make check.... Martyn - do you have any immediate thoughts? It would be particularly useful to know for sure which of dylib or bundle is supposed to be correct! If not I will post something on stackexchange over the weekend.

I have tried this with make vs gmake, Apple's default installed libtool vs libtool 2.4.6, -isysroot [path] vs -framework Accelerate (for lapack/blas) and got identical errors. The invocation and full output is below:

export CFLAGS="-Os -arch x86_64 -framework Accelerate"
export CXXFLAGS="-Os -arch x86_64 -framework Accelerate"
export FFLAGS="-Os -arch x86_64 -framework Accelerate"
export LDFLAGS="-v -arch x86_64"
./configure
make check

[snip]

Making check in test
/Applications/Xcode.app/Contents/Developer/usr/bin/make modules
g++ -DHAVE_CONFIG_H -I. -I.. -I../src/include -I../src/modules -I/opt/local/include -Os -arch x86_64 -framework Accelerate -MT modules-modules.o -MD -MP -MF .deps/modules-modules.Tpo -c -o modules-modules.o test -f 'modules.cc' || echo './'modules.cc
clang: warning: -framework Accelerate: 'linker' input unused
mv -f .deps/modules-modules.Tpo .deps/modules-modules.Po
/bin/sh ../libtool --tag=CXX --mode=link g++ -I/opt/local/include -Os -arch x86_64 -framework Accelerate -L/opt/local/lib -lcppunit -ldl -ldl -v -arch x86_64 -o modules modules-modules.o -lltdl ../src/lib/libjags.la -dlpreopen ../src/modules/base/basemod.la -dlpreopen ../src/modules/bugs/bugs.la -dlpreopen ../src/modules/glm/glm.la ../src/modules/base/libbasetest.la ../src/modules/bugs/libbugstest.la ../src/modules/glm/libglmtest.la
libtool: link: rm -f .libs/modules.nm .libs/modules.nmS .libs/modules.nmT
libtool: link: rm -f ".libs/modules.nmI"
libtool: link: (cd .libs && gcc -Os -arch x86_64 -framework Accelerate -c -fno-builtin "modulesS.c")
clang: warning: -framework Accelerate: 'linker' input unused
libtool: link: rm -f ".libs/modulesS.c" ".libs/modules.nm" ".libs/modules.nmS" ".libs/modules.nmT" ".libs/modules.nmI"
libtool: link: g++ -I/opt/local/include -Os -arch x86_64 -v -arch x86_64 -o .libs/modules modules-modules.o .libs/modulesS.o -Wl,-bind_at_load ../src/modules/base/.libs/basemod.so ../src/modules/bugs/.libs/bugs.so -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../../x86_64 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../.. ../src/modules/glm/.libs/glm.so /Users/matthewdenwood/Documents/Code/JAGS/mercurial/mcmc-jags-code-0-992e8e13d1ab490f1cbd385ce982ca12b481b634/src/jrmath/.libs/libjrmath.dylib -lm -lgfortran -L/opt/local/lib -lcppunit -ldl /usr/local/lib/libltdl.dylib ../src/lib/.libs/libjags.dylib ../src/modules/base/.libs/libbasetest.a ../src/modules/bugs/.libs/libbugstest.a ../src/modules/glm/.libs/libglmtest.a /Users/matthewdenwood/Documents/Code/JAGS/mercurial/mcmc-jags-code-0-992e8e13d1ab490f1cbd385ce982ca12b481b634/src/lib/.libs/libjags.dylib -framework Accelerate
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o .libs/modules -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../../x86_64 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../.. -L/opt/local/lib modules-modules.o .libs/modulesS.o -bind_at_load ../src/modules/base/.libs/basemod.so ../src/modules/bugs/.libs/bugs.so ../src/modules/glm/.libs/glm.so /Users/matthewdenwood/Documents/Code/JAGS/mercurial/mcmc-jags-code-0-992e8e13d1ab490f1cbd385ce982ca12b481b634/src/jrmath/.libs/libjrmath.dylib -lm -lgfortran -lcppunit -ldl /usr/local/lib/libltdl.dylib ../src/lib/.libs/libjags.dylib ../src/modules/base/.libs/libbasetest.a ../src/modules/bugs/.libs/libbugstest.a ../src/modules/glm/.libs/libglmtest.a /Users/matthewdenwood/Documents/Code/JAGS/mercurial/mcmc-jags-code-0-992e8e13d1ab490f1cbd385ce982ca12b481b634/src/lib/.libs/libjags.dylib -framework Accelerate -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '../src/modules/glm/.libs/glm.so' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: [modules] Error 1
make[1]: [check-am] Error 2
make: *** [check-recursive] Error 1

[Matt Denwood]

Problem solved (kind of) - replacing the 6 instances of -bundle with -dynamiclib in the configure file results in a successful make check.

Now I just have to work out how to get autoreconf to do the same and it will be job done... I will look at that on Monday.

[Martyn Plummer]

Thanks Matt.

I think I might be able to work around this by rewriting the testing code. The test code uses symbols in the modules, but you can't just link a program to a module because you get a portability warning from libtool. The work-around that I am currently using is to prelink the modules into the test program (using the libtool option -dlpreopen in the Makefile). That way the module symbols are available.

I suspect this is where the problem lies, and I should rewrite the testing code to actually use dynamic linking of the modules, and not simulate it with pre-linking. Note that pre-linking doesn't work at all on Windows, so I am also unable to run "make check" on Windows. This might kill two birds with one stone.

Let me have a go at this before you do any further investigation.

[Matt Denwood]

Just to confirm that your changes over the weekend have resolved the issue, thanks!

[Martyn Plummer]

Good. I'll close this then. I still can't get it to work on Windows, though (where things are very complicated due to the use of static linking).