Gtest(?) Linking issue

[matt-chan]

Another linking problem. At least it's on linux this time...

I don't know what's going on here. I think there's undefined symbols in some of these programs (although the error suggests there's some libraries compiled with debug symbols, there aren't. I checked with readelf).

The error is at ln 1621-1649. https://travis-ci.org/theochem/qcgrids/jobs/302337015

I'm not sure if we're getting this issue because we're using gtest in conda as opposed to gtest from the github repo. Cellcutoff works fine (and it uses gtest from github). Another possibility is that the gtest package in conda is borked, but that's somewhat unlikely. I did take a look at the meta.yml from the package though, and it's always using gcc/g++, and the versions aren't specified. There's a possibility that we're running into issues because anaconda gtest is linked with an old version of libstdc++. Anaconda was supposed to update their builds, but I guess not all of them switched over (Python did already, which was why we had to do all these rebuilds in the first place).

[tovrstra]

This could be the problem: https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-is-it-not-recommended-to-install-a-pre-compiled-copy-of-google-test-for-example-into-usrlocal

[matt-chan]

Well, I checked that hypothesis I think. The build scripts are identical now but it still doesn't work. Can't figure out what's going on.

The error is in linking at ln2026. It's an unresolved memcpy, which makes no sense to me. https://travis-ci.org/theochem/qcgrids/jobs/302864551. Moreover, conda-build works locally on my machine so I can't figure out what's going on. The build flags are different though somehow. Travis doesn't link against /lib?

This is the offending line (with some stuff cleaned up).
Mine:

/bin/x86_64-conda_cos6-linux-gnu-c++  -std=c++11 -Wall -Wconversion -Wextra -O3 -DNDEBUG  -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/lib -L/lib -rdynamic CMakeFiles/test_qcgrids.dir/test_supergrid.cpp.o CMakeFiles/test_qcgrids.dir/common.cpp.o  -o test_qcgrids -Wl,-rpath,/work/build/qcgrids: ../libqcgrids.so -lcellcutoff ../../googletest-build/googlemock/gtest/libgtest.a ../../googletest-build/googlemock/gtest/libgtest_main.a -lgcov -lpthread ../../googletest-build/googlemock/gtest/libgtest.a -lpthread

Travis:

/bin/x86_64-conda_cos6-linux-gnu-c++  -std=c++11 -Wall -Wconversion -Wextra -O3 -DNDEBUG  -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -rdynamic CMakeFiles/test_qcgrids.dir/test_supergrid.cpp.o CMakeFiles/test_qcgrids.dir/common.cpp.o  -o test_qcgrids -Wl,-rpath,/home/travis/miniconda/conda-bld/qcgrids_1510808838359/work/build/qcgrids:/lib: ../libqcgrids.so /lib/libcellcutoff.so ../../googletest-build/googlemock/gtest/libgtest.a ../../googletest-build/googlemock/gtest/libgtest_main.a -lgcov -lpthread ../../googletest-build/googlemock/gtest/libgtest.a -lpthread 

[tovrstra]

I'll look into this soon. A few other urgent things need to be taken care of... Sorry.

[matt-chan]

I figured it out. When you use compiler(cxx) in Travis, it doesn't provide the glibc library. You've got to provide compiler(c) as well. The best way to prevent this kind of mistake in the future I think is to add an ldd/Mac equivalent call in the test section.

On Thu, Nov 16, 2017 at 2:35 AM Toon Verstraelen ***@***.***> wrote: I'll look into this soon. A few other urgent things need to be taken care of... Sorry. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_-NWXEhugZ_nQzK6Ijp60HGWpA1kgyks5s2-XVgaJpZM4QeihM> .

-- Matt

…

Sent from my phone