Gold linker ld.gold -plugin : unknown option - linker

I'm trying to build Google's ligjingle following the Getting started steps, and I've reached the "Building" section.
When I issue either
ninja -C out/Debug
or
ninja -C out/Release
I get the following error :
I posted the output in pastebin too, if you prefer
ninja -C out/Debug
ninja: Entering directory `out/Debug'
[3/2606] LINK genmacro
FAILED: cc -Wl,-z,now -Wl,-z,relro -Wl,--fatal-warnings -pthread -Wl,-z,noexecstack -fPIC -B/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin -Wl,--disable-new-dtags -m64 -Wl,--icf=none -fuse-ld=gold -Wl,--gdb-index -o genmacro -Wl,--start-group obj/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.genmacro.o -Wl,--end-group
/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold: -plugin: unknown option
/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold: use the --help option for usage information
collect2: error: ld returned 1 exit status
[3/2606] CC obj/net/third_party/nss/ssl/libssl.sslauth.o
ninja: build stopped: subcommand failed.
I tried
ld.gold --help | grep "plugin"
and got :
--plugin PLUGIN Load a plugin library
--plugin-opt OPTION Pass an option to the plugin
So I suppose the error I'm getting is because somewhere in the code, ld.gold is called with -plugin xxx rather than --plugin xxx
I have been "playing" with grep -Hr and different combinations of "plugin" to try to find the problem, but so far I haven't found anything. I suppose it is hidden somewhere in a Makefile.

The problem is not that the -plugin option should be --plugin. ld.gold
accepts both options if it accepts either of them.
But it only accepts either of them if the build of binutils has been
configured with --enable-plugins. Documentation.
When you run ld.gold --help | grep "plugin" the output shows that --plugin is
a recognized option.
Therefore the problem appears to be this:-
/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold
has not been configured with --enable-plugins
When you run ld.gold --help | grep "plugin" you are executing the first ld.gold
that is found on your PATH. It is probably /usr/bin/ld.gold from your distro. You
can find out by running:
which ld.gold
Anyhow, it isn't
/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold
and it is an ld.gold that has been configured with --enable-plugins
If you cd into /home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/
and run:
./ld.gold -plugin
you will get:
./ld.gold: -plugin: unknown option
To fix the problem the ideal solution is to rebuild /home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils
as per that Documentation
If you cannot rebuild these third party binutils from source then it will
probably work if you just copy the system ld.gold detected by which over the one in the
third party binutils, or delete/rename the third party one and replace it with a symlink
to the system one. There is an outside chance that either of the these hacks
would cause you some obscure breakage.

Related

HiGHS fails to link with "undefined reference" errors

On Arch Linux x86_64, Rust 1.66.0 stable, g++ 12.2.0.
I have a problem linking the good-lp crate, and narrowed it down to its indirect dependency highs-sys, even outside my own code.
This happens on a clean checkout of the latest master (c785240), as well as v1.2.2, as well as v0.2.1 (which I used with great success for months through good-lp). So it isn't a new problem in highs-sys, and might very well be a problem with my toolchain.
Versions:
$ cargo --version
cargo 1.66.0 (d65d197ad 2022-11-15)
$ rustc --version
rustc 1.66.0 (69f9c33d7 2022-12-12)
$ cc --version
cc (GCC) 12.2.0
...
$ ld --version
GNU ld (GNU Binutils) 2.39.0
...
Cloning and building:
$ git clone --recursive https://github.com/rust-or/highs-sys
$ cd highs-sys
$ cargo build
...
Finished dev [unoptimized + debuginfo] target(s) in 3m 35s
$ cargo test --lib
Finished test [unoptimized + debuginfo] target(s) in 0.04s
Running unittests src/lib.rs (target/debug/deps/highs_sys-96b0b941fcc31775)
running 2 tests
test bindgen_test_layout___fsid_t ... ok
test bindgen_test_layout_imaxdiv_t ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
All fine so far. The problem happens when we try to use the generated library, even with its own integration tests:
$ cargo test --test test_highs_call
Compiling highs-sys v1.2.2 (/tmp/highs-sys)
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64" "/tmp/rustccbaKBt/symbols.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.110gvlokoswtomfn.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.13y9v90q7e3dvfo2.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.17wo7aophf8in4vn.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.1cdkl7c2apbn7crn.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.1dj1sbwseam0n9ft.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.1hgigplg6qv30idz.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.1ms9q0du418ic26n.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.1tcgu3qw79kuuw1h.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.1vs3h8jyr2rojt51.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.20xdzk038hc30h4j.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.25ph4lcxn1xxn6fn.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.27am5w6h2agsxcl7.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2djhnnv2jm2ibcl3.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2i1j9l2lu5t0k0vu.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2meo5gq21h6h8bqe.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2ol9s57flfu167qp.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2s2g91x597h8e2ey.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2v1cfn4oct7skc3q.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2v9apdn2isgwdl5q.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2wpeqt6tzxghqi56.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2yk7p7w6ixraj427.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2z4b238c1zbjnij6.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.2zlr9mnhg9hyf02g.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.32cfoccwtdvhq06x.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.33nztruk7k2tts8x.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.3cvdzi91jork7mds.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.3fb9xf8nxxzcec41.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.3is6rgf4g5g16vl3.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.3s3dhxd64ny5tive.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.3wn5g0h8q5u3bxky.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4150s6y93i5ma35t.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4335j389sygn8m99.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.44i1r6id1s31acf1.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4injouqsnun7hcvt.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4nb66ozge3nmeuwq.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4p2li2uv9dxcrx2d.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4pz1m3mlzi8imskl.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4tg55omun1u77yh3.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4thto7zkdscqxses.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4vrsyb4og25lcxo8.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.4z0e0rsh1apo67mr.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.50cxv68n1h5055a5.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.515xy9o2bj3al2ry.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.59no2g8u5zmbleot.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.5b574862nrupsals.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.5fu18wwg3p5nmrsh.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.5gi5ablibidmtrpd.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.kjht10drvblu37w.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.ugtef95uy6fok7q.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.xcjfvort5vhydtl.rcgu.o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.3mrzemp57wngq71t.rcgu.o" "-Wl,--as-needed" "-L" "/tmp/highs-sys/target/debug/deps" "-L" "/tmp/highs-sys/target/debug/build/highs-sys-21b14ce07e65289c/out/lib" "-L" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-5678a62cd2e949f2.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-cafb712826ee2a26.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width-bb4ac1585c9c1153.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_std-69fab17bbe87f87e.rlib" "/tmp/highs-sys/target/debug/deps/libhighs_sys-addd17046a23d2a8.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-a11e3ca400b3ed09.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-3e82a3fced649488.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-53a4330185981bcb.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-2a8b57667b4852b5.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-9370462deca12c5a.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-7da763b8d3620472.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-5bde27582a7f5af7.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-1204e05b2d47e3d7.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-43987de2766b6923.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-d6499a0705316aa5.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-c9a27c90d8fbf11e.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-8f159929cbfdfaf1.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-d2f1e8f3bb5cba95.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-9862f486269f442f.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-0434381f2f012ae2.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68549403a59fd02e.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4cefb2045f924a5b.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-272615fc4f10c50d.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-860619b93700e7eb.rlib" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-b73e5b4656934876.rlib" "-Wl,-Bdynamic" "-lstdc++" "-lgomp" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/home/thomas/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro,-znow" "-nodefaultlibs"
= note: /usr/bin/ld: /tmp/highs-sys/target/debug/deps/test_highs_call-e669101ae4108d78.5gi5ablibidmtrpd.rcgu.o: in function `test_highs_call::highs_call':
/tmp/highs-sys/tests/test_highs_call.rs:88: undefined reference to `Highs_lpCall'
collect2: error: ld returned 1 exit status
= note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)
error: could not compile `highs-sys` due to previous error
Similar output happens for the other integration test, test_highs_functions, but with undefined references to all Highs_* functions used in that file.
Verbose build output:
$ cargo build --verbose --test test_highs_call
...
Compiling highs-sys v1.2.2 (/tmp/highs-sys)
Running `rustc --crate-name test_highs_call --edition=2018 tests/test_highs_call.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=e669101ae4108d78 -C extra-filename=-e669101ae4108d78 --out-dir /tmp/highs-sys/target/debug/deps -C incremental=/tmp/highs-sys/target/debug/incremental -L dependency=/tmp/highs-sys/target/debug/deps --extern highs_sys=/tmp/highs-sys/target/debug/deps/libhighs_sys-addd17046a23d2a8.rlib -L native=/tmp/highs-sys/target/debug/build/highs-sys-21b14ce07e65289c/out/lib`
...
... and then the above error again
That rustc command, when run manually, also fails with the same error.
Running the cc command manually fails due to /tmp/rustccbaKBt/symbols.o having been removed, but if I remove that from the command line, the same error occurs again.
The symbol is mentioned as undefined (U) in this file:
$ nm target/debug/deps/test_highs_call-e669101ae4108d78.5gi5ablibidmtrpd.rcgu.o | grep Highs_lpCall
U Highs_lpCall
And it gets defined (T) in this one, which occurs later on the command line, as it should:
$ nm /tmp/highs-sys/target/debug/deps/libhighs_sys-addd17046a23d2a8.rlib | grep Highs_lpCall
nm: lib.rmeta: no symbols
00000000 T Highs_lpCall
However, all the symbols appear at address 00000000 which seems suspicious to my uninformed eye.
I'm honestly not sure if this is a problem with highs, but other libraries that link to C APIs are working fine for me.
Also tried with gcc11, which is still available in the repositories as a separate package:
$ export CC=/usr/bin/gcc-11
$ export CXX=/usr/bin/g++-11
$ export RUSTFLAGS="-C linker=/usr/bin/gcc-11"
This makes it also error out with "undefined reference" errors. Which is weird, because I've been using GCC 11 for quite a while.
But when I set these variables to use clang instead of gcc...
$ export CC=/usr/bin/clang
$ export CXX=/usr/bin/clang++
$ export RUSTFLAGS="-C link-arg=-fuse-ld=lld"
... then it links successfully and tests are green! But this isn't a proper solution.
Any idea what more I could try?
It turns out this was due to link-time optimization (LTO).
libhighs.a was compiled from C++ code by GCC using -flto -fno-fat-lto-objects, causing it to emit only GCC intermediate bytecode into the archive, but not actual machine code. These flags were added by CMake through its option INTERPROCEDURAL_OPTIMIZATION.
But because LTO was not enabled during linking, no machine code was being produced at link time either. Normally the GNU linker would take care of that, but I think the bytecode might have gotten unusable or lost when libhighs.a was linked into a .rlib crate (hypothesis, didn't check). And I don't want to use the GNU linker for Rust code anyway because then I would lose the option to use LTO on Rust code (which always uses LLVM bitcode).
So for now, I think the best solution is to disable LTO on the C++ HiGHS build. I filed an issue with highs-sys and chimed in on an issue with HiGHS to make LTO more optional.

gromacs compilation gives undefined reference error

i would like to use gromacs on my open suse 12.3 platform but am having trouble with it.
when trying to compile an analyzing tool using gmx_template i first got this error:
g++ -L/usr/local/gromacs/lib -o msd msd.o -lmd -lgmx -lfftw3f -lxml2 -lnsl -lm
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: /usr/local /gromacs/lib/libgmx.a(pthreads.c.o): undefined reference to symbol 'pthread_getaffinity_np##GLIBC_2.3.4'
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: note: 'pthread_getaffinity_np##GLIBC_2.3.4' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make: *** [msd] Fehler 1
then i added
/lib64/libpthread.so.0 to the -L options in the makefile
but now i get a lot of errors like this:
/usr/local/gromacs/lib/libgmx.a(pbc.c.o): In function `put_atoms_in_box_omp._omp_fn.0':
pbc.c:(.text+0x862f): undefined reference to `omp_get_num_threads'
i think they are all related to openmp. i do not understand enough of the building process
to enable openmp support (probably -fopenmp) and am at the same time surprised in case
i would have to change the cmake files in order to make gromacs work. i used the quick and dirty install following the gromacs installation instructions on their website.
any suggestions what i can do / did wrong so far ?
i am using gcc 4.7
Here is my gromacs-2018.4 installation process.
pre-installed packages
gcc-8.3.0
cmake-3.14.1
fftw-3.3.8
./configure --prefix=/histor/kang/yangpc/soft/lib/packages/fftw-3.3.8/single_nompi/ --enable-sse2 --enable-avx --enable-float --enable-shared
install gromacs
export PATH=/histor/kang/yangpc//soft/09.system/cmake-3.14.1-Linux-x86_64/bin/:/histor/kang/yangpc//soft/lib/packages/gcc-8.3.0/bin/:$PATH
export CMAKE_PREFIX_PATH="/histor/kang/yangpc/soft/lib/packages/fftw-3.3.8/single_nompi/:/histor/kang/yangpc//soft/lib/packages/gcc-8.3.0/"
export LD_LIBRARY_PATH="/histor/kang/yangpc/soft/lib/packages/gcc-8.3.0/lib64/:$LD_LIBRARY_PATH"
unset LIBRARY_PATH CPATH C_INCLUDE_PATH PKG_CONFIG_PATH CPLUS_INCLUDE_PATH INCLUD
export LD_LIBRARY_PATH=/histor/kang/yangpc/soft/lib/packages/gmp-5.1.3/lib/:/histor/kang/yangpc/soft/lib/packages/mpc-1.0.1/lib/:/histor/kang/yangpc/soft/lib/packages/mpfr-4.0.1/lib/:$LD_LIBRARY_PATH
~/soft/09.system/cmake-3.14.1-Linux-x86_64/bin/cmake .. -DCMAKE_INSTALL_PREFIX=/histor/kang/yangpc/soft/13.DrugDesign/GROMACS/gromacs-2018.4/InstallPos/ -DCMAKE_C_COMPILER="/histor/kang/yangpc/soft/lib/packages/gcc-8.3.0/bin/gcc" -DCMAKE_CXX_COMPILER="/histor/kang/yangpc/soft/lib/packages/gcc-8.3.0/bin/g++"
make
make install

gcc compiler in cygwin does not execute properly (gives up?)

The gcc compiler in cygwin does not execute properly (gives up?) from any folder but /bin. For instance, attempting to compile my code from /bin works, but from /bin/myprogram using the verbose option I get the following message from the compiler:
gcc version 4.5.3 (GCC)
COLLECT_GCC_OPTIONS='-O' '-ansi' '-v' '-c' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api sb.c -quiet -dumpbase sb.c -mtune=generic -march=i686 -ansi -auxbase sb -O -ansi -version -o /tmp/ccyhmnJp.s
Makefile:101: recipe for target `sb.o' failed
make: *** [sb.o] Error 1
Other people have reported similar problems:
http://cygwin.com/ml/cygwin/2010-01/msg00939.html
The solution appears to be to modify the path, although "remove X from the path" sounds like a temporary (and strange) workaround, not a permanent solution, and I don't know what to remove. Regardless I ran cygcheck from /bin and from /bin/myprogram (in which I want to compile). The output follows.
From /bin:
$ cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe
C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.3\cc1.exe
C:\cygwin\bin\cygcloog-0.dll
C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\cygwin\bin\cyggmp-10.dll
C:\cygwin\bin\cygppl_c-4.dll
C:\cygwin\bin\cygppl-9.dll
C:\cygwin\bin\cyggcc_s-1.dll
C:\cygwin\bin\cygstdc++-6.dll
C:\cygwin\bin\cyggmpxx-4.dll
C:\cygwin\bin\cygpwl-5.dll
C:\cygwin\bin\cyggmp-3.dll
C:\cygwin\bin\cygiconv-2.dll
C:\cygwin\bin\cygintl-8.dll
C:\cygwin\bin\cygmpc-1.dll
C:\cygwin\bin\cygmpfr-1.dll
C:\cygwin\bin\cygmpfr-4.dll
C:\cygwin\bin\cygppl_c-2.dll
C:\cygwin\bin\cygppl-7.dll
C:\cygwin\bin\cygz.dll
From /bin/myprogram:
$ cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe
C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.3\cc1.exe
C:\cygwin\bin\cygcloog-0.dll
C:\cygwin\usr\local\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll
C:\cygwin\bin\cyggmp-10.dll
C:\cygwin\bin\cygppl_c-4.dll
C:\cygwin\bin\cygppl-9.dll
C:\cygwin\bin\cyggcc_s-1.dll
C:\cygwin\bin\cygstdc++-6.dll
C:\cygwin\bin\cyggmpxx-4.dll
C:\cygwin\bin\cygpwl-5.dll
C:\cygwin\bin\cyggmp-3.dll
C:\cygwin\bin\cygiconv-2.dll
C:\cygwin\bin\cygintl-8.dll
C:\cygwin\bin\cygmpc-1.dll
C:\cygwin\bin\cygmpfr-1.dll
C:\cygwin\bin\cygmpfr-4.dll
C:\cygwin\bin\cygppl_c-2.dll
C:\cygwin\bin\cygppl-7.dll
C:\cygwin\usr\local\bin\cygz.dll
There are some clear differences but I am not sure what these mean.
Path on my system returns:
$ $PATH
-bash: /usr/local/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS: /cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/ProgramFiles/ImageMagick-6.8.6-Q16 :/cygdrive/c/Ruby193/bin:/cygdrive/c/Program: No such file or directory
Question is, what do I do now? If the answer is change the path variable, what should be removed? Is the path variable stored in one of the bash resource files or do changes have to be made from the command line? Many thanks!
You have various options. The problem is the wrong /usr/local/bin/cygz.dll
Either delete your rogue /usr/local/bin/cygz.dll (preferred),
or fix you PATH
$ export PATH=/usr/bin:/usr/local/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS
Explanation:
On windows the library search path has . before $PATH. So when you are in /bin the right cygz.dll will be found. Otherwise the broken one from your path will be found first.

make error: Building 64-bit GSL in Cygwin

Continuing from here, I am trying to build 64-bit GSL using GCC in Cygwin.
The call to ./configure (CC=x86_64-w64-mingw32-gcc CFLAGS=-m64 ./configure) goes through fine, but the call to make install results, after a whole load of folders are successfully processed, in
./.libs/libgslsiman.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
Makefile:326: recipe for target `siman_tsp.exe' failed
The full call that caused this was
Making all in siman
make2: Entering directory `/cygdrive/f/programming/c/libraries/gslCompiled/gsl-1.15/siman'
/bin/sh ../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -m64 -o siman_tsp.exe siman_tsp.o libgslsiman.la ../rng/libgslrng.la ../ieee-utils/libgslieeeutils.la ../err/libgslerr.la ../sys/libgslsys.la ../utils/libutils.la -lm
libtool: link: x86_64-w64-mingw32-gcc -m64 -o .libs/siman_tsp.exe siman_tsp.o ./.libs/libgslsiman.a ../rng/.libs/libgslrng.a ../ieee-utils/.libs/libgslieeeutils.a ../err/.libs/libgslerr.a ../sys/.libs/libgslsys.a ../utils/.libs/libutils.a
Following advice here, I decided to run a ranlib in the ./siman/.libs directory on the libgslsiman.a file. Since that didn't work, I also tried to pack it myself using a call to ar -t libgslsiman.a.
However, this results in an identical error.
You manually forced use of the cross compiler. However, the rest of the build toolchain will still default to the 32-bit Cygwin versions instead of the 64-bit MinGW ones.
Instead of setting CC=..., pass --host x86_64-w64-mingw32 to ./configure to specify the host environment (ie where the library is going to be used).

Clang link-time optimization doesn't work properly on Fedora 18

I'm a newcomer to clang, so it's likely I'm doing something silly. But I've spent several hours looking for solutions, including searching here, where I haven't found questions addressing -flto with distro-provided packages. The detail of this description are specific to Fedora 18, but I'm having similar problems on Ubuntu 13.04, so the problem isn't specific to Fedora. It's either me or clang.
Problem: I'm trying to compile a simple hello-world program using clang++ -flto to get the benefits of link-time-optimization. Without -flto it works fine. With -flto it fails to link. Invoking as clang -flto -o hello hello.o -v to see the full linker command line, I get:
$ clang++ -flto -o hello hello.o -v
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
"/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../.. -L/lib -L/usr/lib -plugin /usr/bin/../lib/LLVMgold.so hello.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o
/usr/bin/ld: /usr/bin/../lib/LLVMgold.so: error loading plugin
/usr/bin/ld: /usr/bin/../lib/LLVMgold.so: error in plugin cleanup (ignored)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
There seem to be two problems:
clang++ invokes the linker as /usr/bin/ld, and that's not the gold linker. Fedora18 installs gold as /usr/bin/ld.gold. I've tried creating a symlink from /usr/local/bin/ld to /usr/bin/ld.gold, verified that which ld says /usr/local/bin/ld, but clang++ doesn't use that. It seems to be hardwired to /usr/bin/ld.
clang++ invoked the linker with -plugin /usr/bin/../lib/LLVMgold.so. That's wrong, as the Fedora distribution of clang places it at /usr/lib64/llvm/LLVMgold.so.
I have tried manually invoking that linker line above with the following tweaks:
Replace -plugin /usr/bin/../lib/LLVMgold.so with -plugin /usr/lib64/llvm/LLVMgold.so. This yields the error message hello.o: file not recognized: File format not recognized. So the non-gold linker seems to know about plugins but wont take the .o's which contain LLVM bitcode.
Replace /usr/bin/ld with /usr/bin/ld.gold. This works, generates an executable that runs as expected.
Both of the above with --plugin instead of -plugin. This change makes no difference.
So what's the best way for somebody who prefers to stick to the system-provided packages to use clang -flto? I'm hoping there is a config file, or undocumented options or environment variables that will let me override these. Or better, that I'm missing a package and a "yum install ..." will fix it.
I would prefer not to invoke the linker directly, as then my makefiles need to know system objects and libraries that they should be ignorant of (e.g. crt1.o, crtbegin.o, crtend.o). I could also build clang myself, but I'm not seeing anything in its configure script that lets me configure the path of the linker and plugin.
I'm running Fedora 18. The only non-distro packages on the computer are google chrome and VMware Tools (it's a guest inside VMWare Fusion). Versions of relevant Fedora packages (the whole computer is "yum updated" as of today, 29-Apr-2013):
$ yum list --noplugins installed binutils* clang* llvm* gcc*
Installed Packages
binutils.x86_64 2.23.51.0.1-6.fc18 #updates
binutils-devel.x86_64 2.23.51.0.1-6.fc18 #updates
clang.x86_64 3.2-2.fc18 #updates
clang-devel.x86_64 3.2-2.fc18 #updates
clang-doc.noarch 3.2-2.fc18 #updates
gcc.x86_64 4.7.2-8.fc18 #fedora
gcc-c++.x86_64 4.7.2-8.fc18 #fedora
llvm.x86_64 3.2-2.fc18 #updates
llvm-libs.x86_64 3.2-2.fc18 #updates
There is an utility alternatives in Fedora - it allows to subtitute one linker with another on system level:
$ sudo alternatives --display ld
ld - status is auto.
link currently points to /usr/bin/ld.bfd
/usr/bin/ld.bfd - priority 50
/usr/bin/ld.gold - priority 30
Current `best' version is /usr/bin/ld.bfd.
$ sudo alternatives --set ld /usr/bin/ld.gold
About LLVMgold.so location you can only report a bug in Fedora Bugzilla, since the path is built-in in clang sources:
lib/Driver/Tools.cpp: std::string Plugin = ToolChain.getDriver().Dir + "/../lib/LLVMgold.so";
Fedora guys may apply a patch to the Clang's source package, or create a symlink to LLVMgold.so.
There is no changes even in Fedora 20 yet.

Resources