Clang linker issues (from source, to gcc-snapshot)
Asked Answered
D

1

5

I cannot seem to get this to work. I configured with the --with-gcc-toolchain= where after the equals I put the directory where gcc was (/usr/lib/gcc-snapshot/bin).

I also looked into the answers to " clang linker problem" but I do not see how I can get the accepted answer to find the correct location, and the symlink answer would have worked, except that all of the directories that it is searching exist (copying the lib folder from gcc-snapshot to one of the include locations does not seem to help).

As suggested in the other question, the output of clang++ test.cpp -v:

bob@bob:~/programming$ clang++ test.cpp -v
clang version 3.3 (trunk 171350)
Target: x86_64-unknown-linux-gnu
Thread model: posix
"/home/bob/programming/build/Release+Asserts/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -resource-dir /home/bob/programming/build/Release+Asserts/bin/../lib/clang/3.3 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /home/bob/programming/build/Release+Asserts/bin/../lib/clang/3.3/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/bob/programming -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/test-PWiB4M.o -x c++ test.cpp
clang -cc1 version 3.3 based upon LLVM 3.3svn default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/home/bob/programming/build/Release+Asserts/bin/../lib/clang/3.3/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
test.cpp:1:10: fatal error: 'iostream' file not found
#include ^
1 error generated.

clang version 3.3 (trunk revision 171350)

EDIT: There are no .o files in the Release+Asserts folder for the build. Is this normal? If not, why is this the case, and how can I fix it (if I can point it as clang's stdlib, then that works as well).

Edit 2: It also fails to compile int main(){return 0;} as it can't find crtbegin.o. Full output is as follows:

/usr/bin/ld: cannot find crtbegin.o: No such file or directory
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The results after -v are the same as the above, but with the ending error being different.

Config.log:
The full file can be found here, but the first (non-comment) line is: $ ../llvm/configure --with-gcc-toolchain=/usr/lib/gcc-snapshot/gcc

Discussion answered 2/1, 2013 at 7:14 Comment(9)
Does test.cpp compile and link with g++? In your output the code fails to compile because iostream isn't found. -Photoconductivity
@Photoconductivity thats my point. I added another example that fails to compile in edit 2. It compiles just fine with g++Discussion
Where is the iostream file in the place where you installed llvm (your llvm prefix)Opinionative
When you built your gcc-snapshot, did you enable the language c++?Opinionative
@Opinionative yes c++ works with g++ just fine. In the llvm directory, I have iostream.cc, but in the build directory, I have nothing.Discussion
@Discussion from config.log in the llvm source, give us the configure commandline near the top of the file.Opinionative
It'd also be helpful to get a -v output for the int main(){return 0;} code.Opinionative
ok so looks like the llvm can't find iostream.cc and libgcc.a files. We still need the top line from config.log so that someone can try to reproduce it.Opinionative
@Opinionative updated, forgot that before, sorry (note that gcc-snapshot was installed to that location)Discussion
O
4

The issue that we've identified is that gcc was installed with --prefix=/usr/lib/gcc-snapshot configure argument. and llvm was configured with --with-gcc-toolchain=/usr/lib/gcc-snapshot/gcc argument. It should be the same as the gcc installation prefix, i.e. --with-gcc-toolchain=/usr/lib/gcc-snapshot.

The question's current first line says " I configured with the --with-gcc-toolchain= where after the equals I put the directory where gcc was (/usr/lib/gcc-snapshot/bin).", and the current last line says "first (non-comment) line is: $ ../llvm/configure --with-gcc-toolchain=/usr/lib/gcc-snapshot/gcc"

That's puzzling, you might have thought that you had put the flag --with-gcc-toolchain=/usr/lib/gcc-snapshot/bin but you had actually put --with-gcc-toolchain=/usr/lib/gcc-snapshot/gcc

Regardless, I think you should try the following.

  1. remove or rename the build directory (the directory where you ran the configure command, i.e. the directory where you found the config.log file) I assume it's the /home/bob/programming/build directory.
  2. now create /home/bob/programming/build directory again. it should be empty now.
  3. cd /home/bob/programming/build
  4. run the following configure command ../llvm/configure --with-gcc-toolchain=/usr/lib/gcc-snapshot
  5. follow through with the rest of your build process.

The issue seems to be that you didn't specify the gcc-toolchain prefix correctly. It should be the same as the --prefix parameter you used while configuring the gcc.

Report back the results here.

Also see Clang 3.2 build broken after building gcc 4.7

Opinionative answered 11/1, 2013 at 3:35 Comment(10)
yes I was adding that info just as you were posted your comment.Opinionative
There could be other things going on also, but putting the wrong directory as the toolchain parameter could definitely explain what we are seeing here. This might be only the first step towards your eventual success.Opinionative
So its clear (sorry to double check) its --with-gcc-toolchain=/usr/lib/gcc-snapshot not: --with-gcc-toolchain=/usr/lib/gcc-snapshot/binDiscussion
Yes. 10 years of using autotools and 4-6 years of toolchain building support is suggesting that. Still, I'm not going to bet my life on that. :) So let's see what happens. If it doesn't work then report back.Opinionative
The unfortunate thing is that according to llvm.org/viewvc/llvm-project/llvm/trunk/… , the configure script is simply putting that in the header file as the prefix to the gcc installation, without doing any sanity check about whether it can actually find gcc or libgcc where it expects it.Opinionative
oh and reciprocally let me have you double check that you are able to run the command "/usr/lib/gcc-snapshot/bin/gcc -v" and verify that that is the path to the gcc binary that you think you installed. Hopefully you've already started the new build.Opinionative
int main(){return 0;) compiles, but anything referencing the library is undefined reference to std::cout and the like (full output here, and the code is just to cout hello world).Discussion
@Spundun: When you say That's puzzling, you might have thought that you put the flag --with-gcc-toolchain=/usr/lib/gcc-snapshot/bin but you actually put --with-gcc-toolchain=/usr/lib/gcc-snapshot/bin you actually mean: That's puzzling, you might have thought that you put the flag --with-gcc-toolchain=/usr/lib/gcc-snapshot/gcc but you actually put --with-gcc-toolchain=/usr/lib/gcc-snapshot, right?Photoconductivity
Ah yes, I had a typo there. I meant to say the following "That's puzzling, you might have thought that you had put the flag --with-gcc-toolchain=/usr/lib/gcc-snapshot/bin but you had actually put --with-gcc-toolchain=/usr/lib/gcc-snapshot/gcc" Notice that I was using put in past tense.Opinionative
Thank you for this answer! I've been scratching my head over this all day and hadn't found any reference anywhere else to --with-gcc-toolchain and its correct usage!Ache

© 2022 - 2024 — McMap. All rights reserved.