Open matt-chan opened 6 years ago
I have the same.
` (rstudio) smith01s@F0011:~/temp/sodium_1.1/sodium$ gcc -xc -E -v - Reading specs from /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/specs COLLECT_GCC=gcc Target: x86_64-conda_cos6-linux-gnu Configured with: /home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=x86_64-conda_cos6-linux-gnu --prefix=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/gcc_built --with-sysroot=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/gcc_built/x86_64-conda_cos6-linux-gnu/sysroot --enable-languages=c,c++,fortran,objc,obj-c++ --with-pkgversion='crosstool-NG 1.23.0.449-a04d0' --enable-__cxa_atexit --disable-libmudflap --enable-libgomp --disable-libssp --enable-libquadmath --enable-libquadmath-support --enable-libsanitizer --enable-libmpx --with-gmp=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/.build/x86_64-conda_cos6-linux-gnu/buildtools --with-mpfr=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/.build/x86_64-conda_cos6-linux-gnu/buildtools --with-mpc=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/.build/x86_64-conda_cos6-linux-gnu/buildtools --with-isl=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/.build/x86_64-conda_cos6-linux-gnu/buildtools --enable-lto --enable-threads=posix --enable-target-optspace --enable-plugin --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/gcc_built/x86_64-conda_cos6-linux-gnu/sysroot --enable-long-long --enable-default-pie Thread model: posix gcc version 7.3.0 (crosstool-NG 1.23.0.449-a04d0) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64' /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../libexec/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/cc1 -E -quiet -v -iprefix /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/ -isysroot /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../x86_64-conda_cos6-linux-gnu/sysroot - -mtune=generic -march=x86-64 ignoring duplicate directory "/home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/../../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/include" ignoring nonexistent directory "/home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../x86_64-conda_cos6-linux-gnu/sysroot/home/rdonnelly/mc/conda-bld/compilers_linux-64_1534865402226/work/gcc_built/x86_64-conda_cos6-linux-gnu/sysroot/include" ignoring duplicate directory "/home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/../../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/include-fixed" ignoring duplicate directory "/home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/../../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/include"
/home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/include /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/include-fixed /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/include /home/FDSL/smith01s/miniconda3/envs/rstudio/bin/../x86_64-conda_cos6-linux-gnu/sysroot/usr/include End of search list. `
Sorry this has taken a while. I'll get round to it when I can. Really we don't want to be using libtool for libstdc++, in fact some distros remove all .la files from all packages.
Is libtool something you want to run by choice (on .la files as opposed to raw libraries) or is it happening due to some build system?
Can you try deleting these .la files and seeing if your builds work without them?
No problem about the delay. Yeah, I was going to say that it's quite common to kill off libtool archives when packaging for distros. We do it automatically in the Fedora/RHEL build scripts.
It's not my choice to run with .la files. The project author deliberately compiled with them. He seems to be making even more use of libtool as time goes on...
My temporary workaround was to do the linkages before moving to the run prefix. So I run the tests before calling make install
. Not optimal, but it tests for some components at least.
I have a feeling that it's not stable though. The libtool archives (and their hardcoded paths) will make their way downstream into other projects that link against it.
Any solution to this yet?
I think this is no longer an issue.
Actual Behavior
When linking under some conditions, libtools looks for libstdc++.la in rdonnelly's machine.
If it helps, here's a successful libtool call from the same project, which also uses libstdc++
Expected Behavior
Libtool should link to the libstdc++ in the current build_env or prefix.
Steps to Reproduce
conda build on recipe at https://github.com/QuantumElephant/libint-recipe/tree/2.3.1. Prepare to wait for a long build...
Output of conda info