I'm building a project using a GNU tool chain and everything works fine until I get to linking it, where the linker complains that it is missing/can't find crti.o. This is not one of my object files, it seems to be related to libc but I can't understand why it would need this crti.o, wouldn't it use a library file, e.g. libc.a?
I'm cross compiling for the arm platform. I have the file in the toolchain, but how do I get the linker to include it?
crti.o is on one of the 'libraries' search path, but should it look for .o file on the library path?
Is the search path the same for gcc and ld?
crti.o is the bootstrap library, generally quite small. It's usually statically linked into your binary. It should be found in /usr/lib.
If you're running a binary distribution they tend to put all the developer stuff into -dev packages (e.g. libc6-dev) as it's not needed to run compiled programs, just to build them.
You're not cross-compiling are you?
If you're cross-compiling it's usually a problem with gcc's search path not matching where your crti.o is. It should have been built when the toolchain was. The first thing to check is gcc -print-search-dirs and see if crti.o is in any of those paths.
The linking is actually done by ld but it has its paths passed down to it by gcc. Probably the quickest way to find out what's going on is compile a helloworld.c program and strace it to see what is getting passed to ld and see what's going on.
strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test
Open the log file and search for crti.o, as you can see my non-cross compiler:
10616 execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=both", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o"
, "test", "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "-L/usr/lib/gcc/x86_64-linux-g
nu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/../lib", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu
/"..., "/tmp/cc4rFJWD.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_
64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."...], "COLLECT_GCC=gcc", "COLLECT_GCC_OPTIONS=\'-o\' \'test\' "..., "COMPILER_PATH=/usr/lib/gcc/x86_6"..., "LIBRARY_PATH=/usr/lib/gcc/x86_64"..., "CO
LLECT_NO_DEMANGLE="]) = 0
10616 open("/etc/ld.so.cache", O_RDONLY) = 3
10616 open("/usr/lib/libbfd-2.18.0.20080103.so", O_RDONLY) = 3
10616 open("/lib/libc.so.6", O_RDONLY) = 3
10616 open("test", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crt1.o", O_RDONLY) = 4
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crti.o", O_RDONLY) = 5
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtbegin.o", O_RDONLY) = 6
10616 open("/tmp/cc4rFJWD.o", O_RDONLY) = 7
If you see a bunch of attempts to open(...crti.o) = -1 ENOENT, ld is getting confused and you want to see where the path it's opening came from...
I had the same issue while cross-compiling. crti.o was in <sysroot>/usr/lib64 but the linker would not find it.
Turns out that creating an empty directory <sysroot>/usr/lib fixed the issue. It seems that the linker would search for a path <sysroot>/usr/lib first, and only if it exists it would even consider <sysroot>/usr/lib64.
Is this a bug in the linker? Or is this behaviour documented somewhere?
In my case Linux Mint 18.0/Ubuntu 16.04, I have no crti.o at all:
$ find /usr/ -name crti*
I find nothing so I install developer package:
sudo apt-get install libc6-dev
If you find some libs read here
OK I had to reinstall the tool chain, so that the missing files were then included. It seems strange since it should have found it on the gcc path. The main problem I guess was that I had 15 or so different crti.o files on my computer and wasn't point to the correct one. Still doesn't make since but it works now :-) Thanks for your help :-)
I had a similar problem with a badly set-up cross-compiler. I got around it like so:
/home/rob/compiler/usr/bin/arm-linux-gcc --sysroot=/home/rob/compiler hello.c
This assumes /lib, /usr/include and so on exist in the location pointed to by the sysroot option. This is probably not how things are supposed to be done, but it got me out of trouble when I needed to compile a simple C file.
If you are cross-compiling , add sysroot option in LDFLAGS
export LDFLAGS=""--sysroot=${SDKTARGETSYSROOT}" -L${SDKTARGETSYSROOT}/lib -L${SDKTARGETSYSROOT}/usr/lib -L${SDKTARGETSYSROOT}/usr/lib/arm-poky-linux-gnueabi/5.3.0"
I get the same kind of issue on a default Ubuntu 8.04 install. I had to get the libc developer headers/files manually for it to work.
This solved for me (cross compiling pjsip for ARM):
export LDFLAGS='--sysroot=/home/me/<path-to-my-sysroot-parent>/sysroot'
Related
I have been attempting to link a MACHO formatted object file on Linux, but I have failed miserably. So far, I have created the object file by running:
nasm -fmacho -o machoh.o hello.o
I have tried linking using:
clang --target=x86_64-apple-darwin machoh.o
but that failed. I have attempted using GCC, LD, and other linkers but I have still failed miserably. Are there any ideas on how I could solve my problem?
Thank you very much.
The most accessible solution would be lld, the LLVM linker.
lld does not ship with clang, but is a separate package.
sudo apt install lld
If you installed a version of clang that isn't the default (e.g. clang-12 explicitly), then you should use the same version for lld (i.e. lld-12).
Get a MacOS SDK from somewhere. This GitHub repo archives them.
If you're uncomfortable using the above, the "legitimate" way of obtaining it without a Mac would be:
Create an Apple ID
Go to https://developer.apple.com/download/all/
Download the "Command Line Tools for Xcode <version>"
Mount or extract the dmg
Extract the XAR package
For each ".pkg" folder inside, run pbzx <Payload | cpio -i
Find the Library/Developer/CommandLineTools/SDKs/MacOSX.sdk inside.
Feed both of the above to clang:
clang --target=x86_64-apple-darwin -fuse-ld=lld --sysroot=path/to/MacOSX.sdk machoh.o
I have tried linking using: clang --target=x86_64-apple-darwin machoh.o
but that failed.
Failed how? Details matter.
Anyway, there are 3 commonly used linkers on Linux: BFD-ld, Gold, and (newest) LLD.
Of these, Gold is an ELF-only linker, and will not work for Mach-O.
BFD-ld is only configured to support a few emulations (use ld --help to see which ones) in my distribution. BFD does appear to support Mach-O, so it's probably possible to build a Linux BFD-ld cross-linker with such support.
LLD should support Mach-O out of the box, but you are probably not using LLD.
So your first step should be to figure out which linker clang --target=x86_64-apple-darwin ... uses, and then make it use the one which does support Mach-O.
I am trying to compile CVC4 from source on FreeBSD, but I'm running into a hiccup at configuration time - GMP cannot be found, even though the shared object is clearly in a common path:
$> ls /usr/local/lib | grep gmp
libgmp.a
libgmp.la
libgmp.so
libgmp.so.10
libgmp.so.10.1.3
libgmpxx.a
libgmpxx.la
libgmpxx.so
libgmpxx.so.4
libgmpxx.so.4.3.3
$> echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin: \
/usr/local/bin:/root/bin:/usr/local/lib
...and here is the output of ./configure:
...
checking how to hardcode library paths into programs... immediate
checking for __gmpz_init in -lgmp... no
configure: error: GNU MP (libgmp) not found, see http://gmplib.org/
After that, I did a bit of googling and found an article describing an ABI error that I thought could be related. I then compiled GMP from source, but still with no luck being found from the configure script.
What might be causing this error? Any creative ideas or help would be much appreciated. Thank you!
While cvc4 isn't in the FreeBSD ports tree, cvc3 is. Looking at that port's Makefile, you need to call configure with some arguments. I would suggest you try that with cvc4 as well.
I'm trying to link a Qt program I have cross-compiled for a MacOS target on a Linux host. I followed the instructions found here (https://github.com/Tatsh/xchain) to succesfully build gcc, and I can compile and link both simple test programs as on that page to produce executables which run fine on MacOS.
I have built my own Qt from source using this gcc, and I can compile my Qt program without a hitch. The problem comes at the linking stage, when the object files of my program should be linked to the Qt libs, it almost seems as if the Qt libs can't be found at all, or are ignored because they are somehow incompatible.
The object files of my program and the Qt libs I built both seem to be ok:
$ file MainWindow.o
MainWindow.o: Mach-O object i386
$ file /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib.4.8.2
/usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib.4.8.2: Mach-O dynamically linked shared library i386
The g++ invocation goes like this:
$ i686-apple-darwin10-g++ -o myapp.app/Contents/MacOS/myapp
main.o MainWindow.o ...
-L/usr/local/myqt/mac32/Qt-4.8.2/lib -lQtCore -lQtGui ...
Of course there are many more object files and many more Qt libs, I have left them out for brevity.
The errors I get are typical of simply not adding an object or lib to the command line, for example:
...
"QMainWindow::event(QEvent*)", referenced from:
vtable for MainWindowin moc_MainWindow.o
"QDir::~QDir()", referenced from:
_main in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
and it seems that basically every Qt lib is not being found.
I have also tried specifying the lib files directly instead of the -L/path and -lQtFoo combo, and I even tried renaming them from .dylib to .so :)
If I run g++ with -v to see the linker call, then also add -v to that, I can see that the paths being checked for libs look ok:
$ i686-apple-darwin10-ld64 -dynamic -arch i386 -headerpad_max_install_names
-macosx_version_min 10.4 -syslibroot /usr/i686-apple-darwin10
-weak_reference_mismatches non-weak -o myapp.app/Contents/MacOS/myapp
-lcrt1.o /usr/i686-apple-darwin10/SDKs/MacOSX10.6.sdk/usr/bin/../lib/gcc/i686-apple-darwin10/4.2.1/crt3.o
main.o MainWindow.o
...
-L/usr/local/myqt/mac32/Qt-4.8.2/lib -lQtCore -lQtGui ...
-v
#(#)PROGRAM:ld64 PROJECT:odcctools-622.3od16
Library search paths:
/usr/local/myqt/mac32/Qt-4.8.2/lib
/usr/i686-apple-darwin10/usr/X11/lib
/usr/local/myqt/mac32/Qt-4.8.2/lib
/usr/i686-apple-darwin10/usr/lib/i686-apple-darwin10/4.2.1
/usr/i686-apple-darwin10/usr/lib
/usr/i686-apple-darwin10/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1
/usr/i686-apple-darwin10/SDKs/MacOSX10.6.sdk/usr/lib/gcc
/usr/i686-apple-darwin10/usr/lib/gcc/i686-apple-darwin10/4.2.1
/usr/i686-apple-darwin10/SDKs/MacOSX10.6.sdk/usr/i686-apple-darwin10/lib
/usr/i686-apple-darwin10/SDKs/MacOSX10.6.sdk/usr/i686-apple-darwin10/lib
/usr/i686-apple-darwin10/usr/lib
/usr/local/lib
Framework search paths:
/usr/i686-apple-darwin10/Library/Frameworks/
/usr/i686-apple-darwin10/System/Library/Frameworks/
The lib location and setup looks ok:
$ ls -lh /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib*
lrwxrwxrwx. 1 root root 21 Aug 7 05:22 /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib -> libQtCore.dylib.4.8.2
lrwxrwxrwx. 1 root root 21 Aug 7 05:22 /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib.4 -> libQtCore.dylib.4.8.2
lrwxrwxrwx. 1 root root 21 Aug 7 05:22 /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib.4.8 -> libQtCore.dylib.4.8.2
-rwxr-xr-x. 1 root root 2.7M Aug 7 05:22 /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtCore.dylib.4.8.2
The lib contents also seem to be ok, but I am not too familiar with this part... actually I just discovered 'nm' on another question here just now.
$ i686-apple-darwin10-nm /usr/local/myqt/mac32/Qt-4.8.2/lib/libQtGui.dylib.4.8.2 | grep event
U __ZN16QCoreApplication5eventEP6QEvent
U __ZN16QEventTransition5eventEP6QEvent
U __ZN16QEventTransition9eventTestEP6QEvent
U __ZN17QVariantAnimation5eventEP6QEvent
U __ZN19QAbstractTransition5eventEP6QEvent
U __ZN23QCoreApplicationPrivate15eventDispatcherE
U __ZN7QObject11eventFilterEPS_P6QEvent
U __ZN7QObject5eventEP6QEvent
I am also not too familiar with 'name mangling', but I get the feeling it may have something to do with this.
It has been quite a long journey so far with this whole cross-compiling thing, so it sucks to be this close to the end and hit something that really stumps me this much - any advice would be greatly appreciated!
** EDIT ***
I found that if I take out the -dynamic flag for the ld64 call, different function names are shown as missing. For example the missing reference to "QMainWindow::event(QEvent*)" mentioned above becomes:
"__ZN11QMainWindow5eventEP6QEvent", referenced from:
__ZTV10MainWindow in moc_MainWindow.o
And now I can see that these names are indeed, NOT found in the Qt libs I built (configuration issue...?). This didn't enlighten me much as to what should be done to fix the problem, but perhaps it might give somebody else a clue.
I don't have a full answer for you, but I can tell you that the 'U' in your nm output means the symbol is not defined in that executable (or library in this case) but is expected to be defined in an externally linked library, suggesting that something may actually be wrong with that library.
As a side note, you can use the -C argument to nm to have it demangle your C++ symbols.
I managed to get past this problem, although without totally understanding the details of it. Originally I had these two lines in the mkspecs file and although they did not cause any errors when building Qt, commenting them out fixed the problem:
QMAKE_RANLIB = i686-apple-darwin10-ranlib
QMAKE_STRIP = i686-apple-darwin10-strip
I had set these to the cross-compiler executables like this thinking it was necessary, but it seems that everything in the tool-chain is taken care of simply by specifying the correct gcc and g++.
I've a shell on a system without root privileges. I am trying to use a custom library for my new project and it cannot be installed onto the system because I don't have the root privilege. I'm building the library from source. Making the '.o' from the sources has been done. I've tried passing the '.o' file, generated after building the source, as the library argument (-l) to gcc , but gcc says file not found. Any possible workarounds for this?
Just pass the .o as an extra bit just like the rest of your program.
gcc <library.o> <yourprogram.o> -o <executable>
gcc -L/path/to/library/directory
LD_LIBRARY_PATH=/path/to/library/directory:$LD_LIBRARY_PATH ./a.out
Good afternoon,
I am having difficulties with libxml2.
I tried to build the Perl module XML-LibXML which is part of our standard runtime environment. However, this time the installation on a RHEL5 box failed, because the build process complained about missing libxml2:
$> perl Makefile.PL LIB=/foo/lib/perl PREFIX=/foo INSTALLDIRS=site
enable native perl UTF8
running xml2-config...ok (2.7.6)
looking for -lxml2... no
looking for -llibxml2... no
libxml2 not found
However, the file was available. Starting the build with
perl Makefile.PL LIB=/usr/inform/target/lib/perl PREFIX=/usr/inform/target INSTALLDIRS=site
led to more evidence of the real problem:
[...]
Can't load 'blib/arch/auto/Conftest/Conftest.so' for module Conftest: /usr/inform/target/lib/libxml2.so.2: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
at test.pl line 2
[...]
After some investigations I found that the problem appears to be that libxml2.so is created with text relocation:
[tess91#INF-AW] lib$ eu-findtextrel libxml2.so.2.7.6
the file containing the function 'get_crc_table' is not compiled with -fpic/-fPIC
the file containing the function 'crc32' is not compiled with -fpic/-fPIC
the file containing the function 'gzerror' is not compiled with -fpic/-fPIC
[...]
Ans since we have SElinux active on the target machine, linking against libxml.2 failed!
Is there any possibility to create libxml2 properly, or do I have to ask the admin to twist SElinux to allow relocations?
I really can't believe I am the olny one having this problem on Linux with SElinux active. What am I missing?
Any help apprecitated!
Regards,
Stefan
The simplest way is to have your administrator yum install libxml2-devel or even yum install perl-XML-LibXML. Otherwise, see if you can add -fPIC to the CFLAGS in the Makefile.PL.
I assume you are on 32-bit x86, any other architecture wouldn't work without -fPIC.
I just found a possible explanation:
During the build of libxml2 the compiler flag -fPIC is indeed used, so the code is created position independant, BUT:
When creating the shared library, the static libz is linked against it. Is that the source of my problem? That including a static lib in a shared executable taints the library by introducing non-relocatable code?
The fact that the symbols eu-findtextrel should already have pointed me in that direction, since crc32, get_crc_table, etc. look like encryption centered code...