gcc creates a different folder base on its version - c

When I try to rpmbuild something I got this error message
checking for x86_64-redhat-linux-gcc... no
checking for gcc... no
checking for x86_64-redhat-linux-cc... no
checking for cc... no
checking for x86_64-redhat-linux-cl.exe... no
checking for cl.exe... no
And I found out that, the tool are in /usr/bin/gcc48 what I did is link the gcc48 to gcc folder: Which I got the idea from this link https://stackoverflow.com/a/13327320/612920
ln /usr/bin/gcc48 /usr/bin/gcc
And when I tried to run rpmbuild again I got this error message:
checking for x86_64-redhat-linux-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/usr/src/rpm/BUILD/courier-unicode-1.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
error: Bad exit status from /var/tmp/rpm-tmp.jrbnrw (%prep)
What is wrong? I had already installed all development tools and its on its latest versions. Can Somebody help me?
And by the way I am using Amazons Redhat (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC))
UPDATED:
config.log
configure:3499: $? = 0
configure:3488: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-amazon-linux/4.8.2/lto-wrapper
Target: x86_64-amazon-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugu$
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
configure:3499: $? = 0
configure:3488: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3488: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3519: checking whether the C compiler works
configure:3541: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp$
collect2: fatal error: cannot find 'ld'
compilation terminated.
configure:3545: $? = 1
configure:3583: result: no
configure: failed program was:
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3588: error: in `/home/falko/rpm/BUILD/courier-unicode-1.1':
configure:3590: error: C compiler cannot create executables

gcc is one of a number of tools required to build a software package, and as you can see from the error in your config.log, some more are missing from your system:
collect2: fatal error: cannot find 'ld'
It is complaining that it cannot find the system linker (ld).
Before addressing this, I recommend you set the gcc version to be used correctly. Unfortunately the advice you followed from https://stackoverflow.com/a/13327320/612920 is somewhat incomplete.
Redhat based systems provide a mechanism for being able to switch between different implementations of a piece of software at will (for example, different versions). This tool is called alternatives. You should use that to set the GCC version that will be used when you run 'gcc' at the command line. It will update a whole set of symlinks, not just the one you manually set.
sudo alternatives --config gcc
After doing this set the linker to be used:
sudo alternatives --config ld
Note that when I've tried out an AMI linux image, I found that by installing gcc like this:
sudo yum install gcc48
it automatically set the correct 'alternatives' for the newly installed compiler and corresponding linker. I'm not sure how your system got into the state that it is currently in, but if you still have problems after the above procedure, I recommend uninstalling and re-installing gcc and binutils.

After a couple of research I had found out that I am just lacking of ld(GNU linker) tool from RedHat's developer tool set and I also found out that there is an alternative tool just in case ld(GNU linker) is not available, ld.bfd(alternative to the GNU linker) which is in my case it is available. What I did, I make a link from ld.bfd to ld:
ln /usr/bin/ld.bfd /usr/bin/ld
I don't know if it is the proper solution but it works for me.
Reference: Red_Hat_Developer_Toolset

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.

configure: error: C compiler cannot create executables - Mac Sierra

I know these have been posted before, but I'm stuck and can't seem to get anywhere, even by reading copious responses to similar issues to mine.
I get the dreaded "C compiler cannot..." from the title of this post.
I'm on macOS Sierra (long story as to why I'm behind), and have XCode CLT 9.2 installed. I ditched the full XCode app and just went down to the CLT - installed from the Dev area.
Otherwise, I have the latest Homebrew, GCC, Dialog, Libtool, and Automake/Autoconf - some were pre-reqs for the LIRC system I'm trying to get compiled and installed (IR subsystem).
brew config shows that it properly sees the correct XCode CLT, so my guess is that that part is ok.
I get errors once I run the ./configure for this system I'm trying to get up and running...here's the output:
Configuration: .setup.config, executable shell script: configure.sh
Starting the generated shell script which will call configure with the right
parameters...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Volumes/Macintosh HD Giant/Users/Nidocamen/Downloads/LIRC-port-for-Mac-OS-X-master':
configure: error: C compiler cannot create executables
See `config.log' for more details
Thought it could be a permissions issue on the LIRC folder, but it's accessible.
I put in a symlink to ensure that gcc is running gcc-9 in /usr/local/bin and ensured that that path is before /usr/bin (brew doctor isn't complaining about that anymore).
Anyways, I'm otherwise really not sure what's causing this to fail. I've been a developer before, but more on the web app side of things and not at this level.
If anyone has some suggestions, I'd love to hear them...thanks! :)
UPDATE - here's some output from the log that would appear to narrow this down. While the people who created this install claims it works well on recent macOS version, it seems like some of the code used is really outdated and that could be why it's not compiling.
Configured with: ../configure --build=x86_64-apple-darwin16 --prefix=/usr/local/Cellar/gcc/9.2.0 --libdir=/usr/local/Cellar/gcc/9.2.0/lib/gcc/9 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-9 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 9.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
Thread model: posix
gcc version 9.2.0 (Homebrew GCC 9.2.0)
configure:3322: $? = 0
configure:3311: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3322: $? = 1
configure:3311: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3322: $? = 1
configure:3342: checking whether the C compiler works
configure:3364: gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.9 conftest.c >&5
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
configure:3368: $? = 1
configure:3406: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define PACKAGE "lirc"
| #define VERSION "0.9.1-git"
| /* end confdefs.h. */
I had a similar issue, and in my case the "library not found for -lSystem" was caused by a line in my .bash_profile
alias openclc=/System/Library/Frameworks/OpenCL.framework/Libraries/openclc
No idea why I had put that in there, but unalias-ing it fixed my issues...

R configure error that C99 double complex is required

I am trying to update R to version 3.5.3 on my Centos 7 server with a GCC compiler of version 8.2.0. But when I tried to configure in the home directory of R-3.5.3, it was stuck with the following error:
checking complex.h usability... no
checking complex.h presence... no
checking for complex.h... no
checking whether C99 double complex is supported... no
configure: error: Support for C99 double complex type is required.
The version information of my GCC compiler is as follows:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-libmpx --with-system-zlib
Thread model: posix
gcc version 8.2.0 (GCC)
Could anyone help me to get rid of such a problem?
Thanks!
EDIT:
After I checked the discussion, I thought the complex.h might be included wrongly and then I double checked in the config.h. But it turned out to be the included complex.h was the new header for gcc 8.2.0 as follows:
configure:38022: checking complex.h usability
configure:38022: gcc -c -g -O2 -I/usr/local/include/c++/8.2.0/ conftest.c >&5
Below them, there was another error which was:
/usr/local/include/c++/8.2.0/complex.h:29:10: fatal error: bits/c++config.h: No such file or directory
I tried again to configure with options --includedir and CXXFLAGS but both didn't work.
I found the same issue and fixed it by add gcc-9.3.0_install/include/c++/9.3.0/x86_64-pc-linux-gnu/ into include path.
when only gcc-9.3.0_install/include/c++/9.3.0/ was added into the include path, the <bits/c++config.h> could not be found and lead to this error !
Lidong

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

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