Building a 32-bit app in 64-bit Ubuntu - gcc

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?

Related

What default libraries does -nolibc remove?

I am working on a project which eventually requires me to link my code against my customized version of libc, libstdc++ and libgcc. Now I am learning what libraries are linked by default.
I tried to compile my project code with -nolibc and manually provide the needed libraries in the argument list.
g++ -fuse-ld=gold -O2 -o main -static -nolibc main.cpp -lgcc -lm -lc
I got the following error, showing that I missed some libraries.
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_eh.a(unwind-dw2-fde-dip.o):function _Unwind_Find_FDE: error: undefined reference to 'dl_iterate_phdr'
Which library is missing here?

how can I fix ld not ignoring bad system libraries in favor of my local libraries?

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'

linker --as-needed flag not pruning libraries

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.

Static -libgfortran in library build

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.

Can't link with shared library

I can't link my program with shared library located in non-standart OSX lib directory. I've got this library from MacPorts and it's located in /opt/local/lib:
$ ls /opt/local/lib/libgmp*
/opt/local/lib/libgmp.10.dylib /opt/local/lib/libgmpxx.4.dylib
/opt/local/lib/libgmp.a /opt/local/lib/libgmpxx.a
/opt/local/lib/libgmp.dylib /opt/local/lib/libgmpxx.dylib
/opt/local/lib/libgmp.la /opt/local/lib/libgmpxx.la
I've found that one can use DYLD_FALLBACK_LIBRARY_PATH, but it not works for me:
$ DYLD_LIBRARY_PATH=/opt/local/lib gcc ab.c -lgmp
ld: library not found for -lgmp
collect2: ld returned 1 exit status
At runtime, DYLD_LIBRARY_PATH helps dynamic linker to locate libraries from non-standard directories.
In your case, you are still in compilation phase.
For gcc to know about these extra directories to search, you could use -L switch.
e.g.
gcc ab.c -L/opt/local/lib -lgmp

Resources