I am trying to build a library that only has static references to libgfortran (and preferably libgcc also).
However, if I use the linker flags
-static -lgfortran -static-libgfortran -static-libgcc
on OS X I get
ld: library not found for -lcrt0.o
collect2: error: ld returned 1 exit status
and if I try to use
-shared -lgfortran -static-libgfortran
I get
Undefined symbols for architecture x86_64:
"_quadmath_snprintf", referenced from:
_write_float in libgfortran.a(write.o)
"_strtoflt128", referenced from:
__gfortrani_convert_real in libgfortran.a(read.o)
__gfortrani_convert_infnan in libgfortran.a(read.o)
and everything compiles fine (but has a dynamic link to libgfortran and libgcc) if I use -dynamiclib -lgfortran.
It would appear that gcc is not build statically on OS X.
How do I build my library so that end-users don't need to have gfortran or gcc installed?
I'm using the macports version of gcc but I'm prepared to use another distributor of gfortran/gcc if it allows me to do this.
-dynamiclib -lgfortran -static-libgfortran \
/opt/local/lib/gcc47/libquadmath.a -static-libgcc
seems to do the trick!
The bizarre thing was figuring out that I needed to add a full path to the libquadmath.a, which feels like a bug with gcc/gfortran to be honest.
Related
I'm trying to build the newest gcc on my redhat box. I've downloaded and built the latest gmp, mpfr and mpc, per requirements and installed them in my local libraries. From the config.log file I have the following given below. Clearly the system version of mpfr is broken, and I want the configure to ignore it. I have set LIBRARY_PATH and LD_LIBRARY_PATH to point to my local installation /u/victor/lib. Since I'm running a configure script, it's not reasonable for me to try to change command line options for gcc. How do I fix this?
gcc -o conftest -g -O2 conftest.c -L/u/victor/lib -L/u/victor/lib -L/u/victor/lib -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: warning: libmpfr.so.1, needed by /u/victor/lib/libmpc.so, may conflict with libmpfr.so.4
/usr/bin/ld: __gmpfr_cache_const_euler: TLS definition in /u/victor/lib/libmpfr.so section .tdata mismatches non-TLS definition in /usr/lib64/libmpfr.so.1 section .data
What's even more confusing, is that when I compile conftest.c and then
gcc -o conftest conftest.o -lmpc -lmpfr -lgmp
with export LD_LIBRARY_PATH=/u/victor/lib it gives the errors below. I've check libmfpr.so with nm and the three "undefined" symbols are there.
/u/victor/lib/libmpc.so: undefined reference to `mpfr_min_prec'
/u/victor/lib/libmpc.so: undefined reference to `mpfr_set_zero'
/u/victor/lib/libmpc.so: undefined reference to `mpfr_get_z_2exp'
I'm running into an issue after upgrading gcc from 4.1.1 to 4.7.2. The problem is that the ld --as-needed flag is not pruning libraries that are not required if enough libraries with inter dependencies are listed.
For example, if I build a simple program that doesn't need any special libraries, but includes them on the build line, as such
gcc -m32 test.c -Wl,--as-needed -L/usr/local/lib -lrt -lprojcommon -lproj -lrte -o test
then it builds fine and the --as-needed flag does it's job pruning out all of the listed libs that are not needed.
ldd test
linux-gate.so.1 => (0x00bfc000)
libc.so.6 => /lib/libc.so.6 (0x001ac000)
/lib/ld-linux.so.2 (0x0018a000
However, if I add one more library (in this case crypto), then the build fails with undefined reference errors.
gcc -m32 test.c -Wl,--as-needed -L/usr/local/lib -lcrypto -lrt -lprojcommon -lproj -lrte -o test
/usr/local/lib/librte.so: error: undefined reference to 'tla_decap_data'
/usr/local/lib/librte.so: error: undefined reference to 'do_db'
collect2: error: ld returned 1 exit status
This exact same build worked with 4.1.1, but started failing with 4.7.2.
This is part of a general build infra and libraries included on the build line are generic and expected to be pruned via --as-needed. I could fix this with --allow-shlib-undefined, but I'd prefer to find real unresolved symbols at build time. If I do set --allow-shlib-undefined, then I end up with the same set of required libs as the build that worked.
Any insight would be appreciated.
I am trying to build an small sample CUDA code matrixMul.cu in XCode 4.5.2. I did:
a custom script which runs nvcc to compile the .cu file to an object file.
then let xcode to link it with cuda lib to produce the final executable matrixMul
However, in the linking stage, xcode always runs gcc on the .o file instead of g++, and becos of this it results in error:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -arch x86_64 -isysroot ...
Undefined symbols for architecture x86_64:
"std::ios_base::Init::Init()", referenced from:
__static_initialization_and_destruction_0(int, int)in matrixMul.o
"std::ios_base::Init::~Init()", referenced from:
___tcf_0 in matrixMul.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
I don't know how to make XCode to run g++ instead of gcc to link the object file. I have only the .cu file in the project so no .cpp to indicate it's c++. However, I DO choose C++ when I created the xcode project in the very beginning. It runs gcc for me regardless I choose Apple LLVM compiler or LLVM GCC in the build settings.
Thank you!
Gary
It turns out that I can't force XCode to use g++ for linkage, but has a workaround where I add -lstdc++ to the "Other linker flags" section, making gcc link the c++ lib for me.
It works for now, but I am not too sure if this the only/best solution. Please let me know if anyone has other solution.
Gary
I'm trying to make dynamic lib from set of .o files, but when i do
gcc -dynamiclib -current_version 1.0 mymod.o -o mylib.dylib
or
ld *.o -o mylib.dylib
i get a lot of errors like:
"_objc_msgSend", referenced from:
-[NSObject(NSObject_SBJSON) JSONFragment] in NSObject+SBJSON.o
"operator new(unsigned long)", referenced from:
MStatistic::instance() in MStatistic.o
StatisticProfileLoggingObserver::instance() in StatisticObserver.o
ld: symbol(s) not found for architecture x86_64
Can you please help me, how to solve it and get my .dylib?
You can pass -undefined dynamic_lookup as an option to ld, or:
-Wl,-undefined -Wl,dynamic_lookup to gcc or clang (which passes it to the linker).
From this line:
ld: symbol(s) not found for architecture x86_64
it sounds like you are building some libraries that have make files that only build for 32-bit architectures.
You need to modify the makefiles for all the libraries / frameworks you're building to build both 32-bit and 64-bit; and in a practical sense, all shipping MacOS machines are 64-bit capable so it may just be safe to build only for 64-bit.
In your compile / linking lines, add something like this: "-arch x86_64" and that should compile things for the 64-bit side. To do both 32 & 64-bit, you'll basically need to duplicate the compile & link lines with their own "-arch i386" and "-arch x86_64" lines.
After hours of googling, I decide to give up and ask you experts. I am trying to build a 32-bit application (xgap if anyone interested) in my 64 Ubuntu 11.10. I added the CFLAGS=-m32 and the LDFLAGS=-L/usr/lib32 in the makefile. The objects are built into 32 bit fine. The last step is to link all the objects and libraries for X windows into this executable---xgap. Somehow it keeps giving me this error:
gcc -o xgap xcmds.o utils.o gapgraph.o gaptext.o pty.o popdial.o xgap.o selfile.o -L/usr/lib32 -lXaw -lXmu -lXt -lXext -lX11 -lSM -lICE
/usr/bin/ld: skipping incompatible /usr/lib32/libXmu.so when searching for -lXmu
...
/usr/bin/ld: i386 architecture of input file `xcmds.o' is incompatible with i386:x86-64 output
...
I have installed ia32-libs and mutilib support. I think I just need to force the linker to generate a i386 output. I tried to put two ld flags in my gcc command as shown above: -melf_i386 and -oformat elf32-i386. But what happens is that gcc doesn't search for the 32 bit library in /usr/lib32 anymore. I wonder if I need to put those flags in some fixed order?
Thanks for any idea and help!
EDIT: when I add the -m32 flag in my last gcc command (the linking stage I believe), even if I have the -L/usr/lib32 flag in place, gcc doesn't search in /usr/lib32 anymore ( really weird...) and generates the following error:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../libXaw.so when searching for -lXaw
/usr/bin/ld: skipping incompatible /usr/lib/libXaw.so when searching for -lXaw
/usr/bin/ld: cannot find -lXaw
collect2: ld returned 1 exit status
Any one has any idea why this happens? I am using the auto tool to configure and make. I am really good at modifying those script files.
You need to use link with -m32 as well.
gcc -m32 -o xgap xcmds.o utils.o gapgraph.o gaptext.o pty.o popdial.o xgap.o selfile.o -L/usr/lib32 -lXaw -lXmu -lXt -lXext -lX11 -lSM -lICE
All things considered, I think you should be able to drop the -L/usr/lib32 when using -m32.
I solved the problem. I think that gcc was expecting a static library archive. I used the getlibs script from http://ubuntuforums.org/showthread.php?t=474790 to download all the .a archives needed for linking. Then gcc worked. I think gcc did search in /usr/lib32 directory but didn't find the .a archives so went on to search in the standard directory which is /usr/lib, where it finds the incompatible *.so files.
But then the question is: the *.so files in /usr/lib32/ from package ia32-libs doesn't really have the libraries needed for linking? What are those files in /usr/lib32/ used for?