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.
Related
Problem with linking portaudio into an c program on Linux.
System: Linux Ubuntu 20.4 i5 16 GB
ALSA and pulseaudio were preinstralled.
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
gcc -Wall wm_1.c -lm libportaudio.a -o wm_1
The linker gives me more than 100 error messages all of type "undefined reference"
Here 2 examples out of >100
/home/max/Desktop/dev/portaudio/src/hostapi/alsa/pa_linux_alsa.c:504: undefined reference to snd_pcm_status_get_delay' /home/max/Desktop/dev/portaudio/src/hostapi/oss/pa_unix_oss.c:1778: undefined reference to __pthread_unregister_cancel'
So its obvious that the named parameter/function can not be found.
The error messages all point to source files in the source directory (the directory of the portaudio
package I downloaded to creatie the libs which were all created without error.
The libs are in /usr/local/..
libportaudio.a libportaudio.la libportaudio.so libportaudio.so.2 libportaudio.so.2.0.0 pkgconfig python3.8
and I copied libportaudio.a into the project directory. The lib has a a size of 1.1 MB .
if I use the dynamic libportaudio.so I get the error messages at run time.
I suspect that something went totally wrong with creating the libraries but I have no idea how to solve that
Other option:
Linking parameter or files missing ?
Header file ?
The same program compiles, links and runs without any problem on a iMac OS 10.13.6
where I used the dynamic lib .dylib.
gcc -v wm_1.c libportaudio.dylib -o wm_1
From the documentation:
Note that you will usually need to link with the approriate libraries that you used, such as ALSA and JACK, as well as with librt and libpthread. For example:
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o YOUR_BINARY
A little googling goes a long way...
This works:
gcc -Wall wm_1.c -lm libportaudio.a -lasound -pthread -o test.
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o YOUR_BINARY
I used that page and the command line at the begin using all 3 parameter but got errors, probably of misspelling, so I gave up on that (also because on the Mac OS it was not necessary). It now links without errors using -lasound and -pthread only (-pthread alone gives still errors and the use/not use of -ljack makes no difference).
I get some errors when I run the program but probably because of missing or wrong ALSA parameter settings. I found -pthread but I could not find -ljack and -lasound.
So the question: what are this 2 parameter doing?
It must be link parameter, but where is the documentation, I searched ld and gcc and did not find anything, while -pthread is documented.
I am getting the below error during ./configure.
configure:3429: checking whether the C compiler works
configure:3451: gcc -m32 -D_FILE_OFFSET_BITS=64 -m32 conftest.c >&5
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
configure:3455: $? = 1
configure:3493: result: no
configure:3498: error: in `/root/cjk/1.x/src/externals/mecab':
configure:3500: error: C compiler cannot create executables
I have tried couple of solutions mentioned in internet but to no avail.
I have installed complete Developers package in the machine.
I have installed glibc-devel.i686 package as well.
I ran into the exact same issue (CentOS 6.5 x64, gcc 4.4.7). I made sure yum install glibc-devel.i686 was performed. A quick find / -name "libgcc_s.*" revealed:
/lib64/libgcc_s.so.1
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libgcc_s.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
So, perhaps you can try the workaround suggested here:
Add the absolute path to the gcc_s library on the link line, OR
(Recommended) If the library's filename has any major and minor version numbers appended to it, simply create a soft link to the library in the same location without the major and minor version numbers in the target filename.
I settled for compiling/linking my application statically by adding -static to my gcc invocation. So,
gcc -static -m32 ...
In that case make sure yum install glibc-static.i686 is done.
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).
I'm going through a book focusing on x86 programming (Professional Assembly Language, WROX 2005). I had some problems last night and I was hoping to sort this out before returning home today so I can get a running-start and continue the text. My machine runs x64 Ubuntu (11.04 if I'm not mistaken) so the text focusing on 32bit x86 is slightly 'outdated' (I have to add --32 when assembling etc).
I am trying to dynamically link C-library functions with my assembly program but I am unsuccesfull (below commands are from memory).
ld -dynamic-linking /lib/ld-linux.so.2 -o complex -lc complex.o -m elf_i386
Running the above command in Linux gives me the message that it can't understand -lc. Okay, so I removed it.
ld -dynamic-linking /lib/ld-linux.so.2 -o complex complex.o -m elf_i386
I then get the notification that 'printf' is not recognised. The hopes was for the dynamic linker to link to the library but it does not seem to do so. Going to \lib\ I could not locate ld-linux.so.2 (strangely it didn't give me an error on this) but I did locate ld-linux-86-64.so.2. My code is 32bit but I thought what the heck, let's try this:
ld -dynamic-linking /lib/ld-linux-86-64.so.2 -o complex complex.o -m elf_i386
Still it gave the same error that 'call printf' was not recognized.
Need help dynamically linking C library functions with my 32bit Assembly program using 64bit Linux and standard GNU tools.
Sounds like you need to install the 32-bit C-runtime. Under Fedora this is:
yum install glibc-devel.i686
But I don't know the name of the equivalent Ubunutu package; perhaps:
apt-get install libc6-dev-i386
It is almost always a bad idea to try to construct a ld command line yourself. Let GCC do it for you; it automatically handles all sorts of subtleties that you don't want to have to worry about. For a 32-bit program, you do need one special command line switch, -m32:
gcc -m32 -o complex complex.o
If you have more .o files, just stack them up at the end. If you need to link against any system libraries other than libc, put appropriate -lwhatever options after all the object files.
trojanfoe is also correct; the 32-bit toolchain is an optional component. But you need more than just the 32-bit C library. Try this first:
apt-get install gcc-multilib
it should pull in most of what you need.
Try the following order please(suppose your code fil is try.s):
as --32 -g -o try.o try.s
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -lc -o try try.o
For x86-64 format executable fileļ¼
as -g -o try.o try.s
ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 -lc -o try try.o
I'm trying to compile a C program under Linux. However, out of curiosity, I'm trying to execute some steps by hand: I use:
the gcc frontend to produce assembler code
then run the GNU assembler to get an object file
and then link it with the C runtime to get a working executable.
Now I'm stuck with the linking part.
The program is a very basic "Hello world":
#include <stdio.h>
int main() {
printf("Hello\n");
return 0;
}
I use the following command to produce the assembly code:
gcc hello.c -S -masm=intel
I'm telling gcc to quit after compiling and dump the assembly code with Intel syntax.
Then I use th GNU assembler to produce the object file:
as -o hello.o hello.s
Then I try using ld to produce the final executable:
ld hello.o /usr/lib/libc.so /usr/lib/crt1.o -o hello
But I keep getting the following error message:
/usr/lib/crt1.o: In function `_start':
(.text+0xc): undefined reference to `__libc_csu_fini'
/usr/lib/crt1.o: In function `_start':
(.text+0x11): undefined reference to `__libc_csu_init'
The symbols __libc_csu_fini/init seem to be a part of glibc, but I can't find them anywhere! I tried linking against libc statically (against /usr/lib/libc.a) with the same result.
What could the problem be?
/usr/lib/libc.so is a linker script which tells the linker to pull in the shared library /lib/libc.so.6, and a non-shared portion, /usr/lib/libc_nonshared.a.
__libc_csu_init and __libc_csu_fini come from /usr/lib/libc_nonshared.a. They're not being found because references to symbols in non-shared libraries need to appear before the archive that defines them on the linker line. In your case, /usr/lib/crt1.o (which references them) appears after /usr/lib/libc.so (which pulls them in), so it doesn't work.
Fixing the order on the link line will get you a bit further, but then you'll probably get a new problem, where __libc_csu_init and __libc_csu_fini (which are now found) can't find _init and _fini. In order to call C library functions, you should also link /usr/lib/crti.o (after crt1.o but before the C library) and /usr/lib/crtn.o (after the C library), which contain initialisation and finalisation code.
Adding those should give you a successfully linked executable. It still won't work, because it uses the dynamically linked C library without specifying what the dynamic linker is. You'll need to tell the linker that as well, with something like -dynamic-linker /lib/ld-linux.so.2 (for 32-bit x86 at least; the name of the standard dynamic linker varies across platforms).
If you do all that (essentially as per Rob's answer), you'll get something that works in simple cases. But you may come across further problems with more complex code, as GCC provides some of its own library routines which may be needed if your code uses certain features. These will be buried somewhere deep inside the GCC installation directories...
You can see what gcc is doing by running it with either the -v option (which will show you the commands it invokes as it runs), or the -### option (which just prints the commands it would run, with all of the arguments quotes, but doesn't actually run anything). The output will be confusing unless you know that it usually invokes ld indirectly via one of its own components, collect2 (which is used to glue in C++ constructor calls at the right point).
I found another post which contained a clue: -dynamic-linker /lib/ld-linux.so.2.
Try this:
$ gcc hello.c -S -masm=intel
$ as -o hello.o hello.s
$ ld -o hello -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o hello.o -lc /usr/lib/crtn.o
$ ./hello
hello, world
$
Assuming that a normal invocation of gcc -o hello hello.c produces a working build, run this command:
gcc --verbose -o hello hello.c
and gcc will tell you how it's linking things. That should give you a good idea of everything that you might need to account for in your link step.
In Ubuntu 14.04 (GCC 4.8), the minimal linking command is:
ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 \
/usr/lib/x86_64-linux-gnu/crt1.o \
/usr/lib/x86_64-linux-gnu/crti.o \
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/ \
-lc -lgcc -lgcc_s \
hello.o \
/usr/lib/x86_64-linux-gnu/crtn.o
Although they may not be necessary, you should also link to -lgcc and -lgcc_s, since GCC may emit calls to functions present in those libraries for operations which your hardware does not implement natively, e.g. long long int operations on 32-bit. See also: Do I really need libgcc?
I had to add:
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/ \
because the default linker script does not include that directory, and that is where libgcc.a was located.
As mentioned by Michael Burr, you can find the paths with gcc -v. More precisely, you need:
gcc -v hello_world.c |& grep 'collect2' | tr ' ' '\n'
This is how I fixed it on ubuntu 11.10:
apt-get remove libc-dev
Say yes to remove all the packages but copy the list to reinstall after.
apt-get install libc-dev
If you're running a 64-bit OS, your glibc(-devel) may be broken. By looking at this and this you can find these 3 possible solutions:
add lib64 to LD_LIBRARY_PATH
use lc_noshared
reinstall glibc-devel
Since you are doing the link process by hand, you are forgetting to link the C run time initializer, or whatever it is called.
To not get into the specifics of where and what you should link for you platform, after getting your intel asm file, use gcc to generate (compile and link) your executable.
simply doing gcc hello.c -o hello should work.
Take it:
$ echo 'main(){puts("ok");}' > hello.c
$ gcc -c hello.c -o hello.o
$ ld hello.o -o hello.exe /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtn.o \
-dynamic-linker /lib/ld-linux.so.2 -lc
$ ./hello.exe
ok
Path to /usr/lib/crt*.o will when glibc configured with --prefix=/usr