Why is gcc failing with 'unrecognized command line option "-L/lusr/opt/mpfr-2.4.2/lib"'? - c

My sysadmin recently installed a new version of GCC, in /lusr/opt/gcc-4.4.3. I tested it as follows:
mike#canon:~$ cat test.c
int main(){
return 0;
}
mike#canon:~$ gcc test.c
/lusr/opt/gcc-4.4.3/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
After informing my sysadmin about this, he said to add /lusr/opt/mpfr-2.4.2/lib:/lusr/opt/gmp-4.3.2/lib to my LD_LIBRARY_PATH. After doing this, I get the following error:
mike#canon:~$ gcc test.c
cc1: error: unrecognized command line option "-L/lusr/opt/mpfr-2.4.2/lib"
First, my sysadmin wasn't entirely sure this was the best workaround(though he did say it worked for him...), so is there a better solution?
Second, why am I getting a linker error from cc, and how can I fix it?
Some information which may be helpful:
mike#canon:~$ env | grep mpfr
OLDPWD=/lusr/opt/mpfr-2.4.2/lib
LD_LIBRARY_PATH=/lusr/opt/mpfr-2.4.2/lib:/lusr/opt/gmp-4.3.2/lib:
mike#canon:~$ echo $LDFLAGS
(the above is a blank line)

I would suggest that your sysadmin needs to install the GMP and MPFR libraries from the build machine into the same location on your machine. (There's also the MPC library which you may also need.) Alternatively, your sysadmin needs to install a rebuild of GCC - preferably version 4.5.2 since that is (AFAIK) current - with the correct settings for where the GMP and MPFR libraries will be installed on your machine.
You shouldn't need to set LD_LIBRARY_PATH to use GCC. If you need to do so, it indicates that it was not built for the machine where it is running. Key libraries are missing.
To go further with your debugging, you probably need to use:
gcc -v test.c
This will show you the command lines executed. There is no call for the -L option (which affects the way programs are linked) to be passed to the phase 1 compiler.

This looks like some buggy argument parsing by gcc (it shouldn't complain about -Lfoo).
Can you try setting
LD_LIBRARY_PATH=\ /lusr/opt/mpfr-2.4.2/lib:/lusr/opt/gmp-4.3.2/lib
so that there's a leading space before that mpfr library path?

Related

How to compile GCC cross-compiler?

I am trying to compile GCC for i586-elf but every time I run the 'configure' file with this command:
./configure --target=$TARGET --prefix=$PREFIX --disable-nls --enable
languages=c --without-headers --with-gmp=$PREFIX --with-mpc=$PREFIX
--with-mpfr=$PREFIX
Then it gives me this error:
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... no.
Although I have specified where gmp, mpfr, and mpc are located. And I have the latest versions of them. Is there anything I am missing?
Unless you really care about specific gmp/mpfr etc versions I suggest you run the contrib/download_prerequisites script from the top-level GCC source directory and then omit the --with-gmp=$PREFIX --with-mpc=$PREFIX --with-mpfr=$PREFIX from your configure line. The download_prerequisites script will download and unpack the right versions of the libraries that your GCC version needs and it will create the right symlinks in the right places

compiling Vim 7.4 under AIX 6.1

I have a problem while compiling Vim 7.4 under AIX 6.1.
My options for the configure script are: "--prefix /opt/freeware/bin" and "--enable-pythoninterp".
There where no Errors while running the configure Script but when I try to run "make" I get the error message:
cd src && make first
cc -qlanglvl=extc89 -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -g -o objects/regexp.o regexp.c "regexp_nfa.c"
line 4410.1: 1506-046 (S) Syntax error.
make: 1254-004 > The error code from the last command is
1.
Stop. make: 1254-004 The error code from the last command is 2.
Stop.
Does anyone know what to do?
I had compiled Vim 7.4 in my home directory so I know that there is a workaround but I can't find it anymore.
AIX's built in make (based on standard AT&T make) is not compatible with the Makefiles built by autoconf tools. Use GNU make (gmake) instead. You may already have it installed (check /opt/freeware/bin), install from the Linux Toolbox for AIX set (from IBM), or from one of the websites providing prebuilt GNU tools for AIX systems (perzl, bullfreeware, etc). Just provide an alias from make to gmake, or override the use of make in the Makefile itself.

Build 'libconfig' as a 32-bit library

I am trying to use the libconfig (http://www.hyperrealm.com/libconfig/ ) for a little utility I am trying to write. I am trying to build libconfig then copy the library file (libconfig.a) to my utility's directory. When I build my utility I get warnings about the architecture being incompatible. Here is one of the specific warning messages I receive.
/usr/bin/ld: warning: i386:x86-64 architecture of input file 'libconfig.a(libconfig_la-libconfig.o)' is incompatible with i386 output
I am building on a Red Hat Enterprise Linux Server release 5.10 machine (uname -m produces 'x86_64'). I tried building libconfig with the following:
configure --disable-cxx CFLAGS='-m32' LDFLAGS='-m32'
But unfortunately, this didn't seem to produce the correct library as I still see the same warnings. There are other utilities that are created during the build process and all utilities share make common make directives which are specifying CFLAGS = -m32 -Wextra -Wall -Werror -Os and LDFLAGS = -m32, so I am unable to change this behavior.
I have also tried configure --disable-cxx CFLAGS='-arch i386' LDFLAGS='-arch i386, but this command line will not build the library.
Does anyone know how to build the libconfig as a 32-bit library to be consumed correctly.
Thanks,
Mark
The configure script will ignore arguments like CFLAGS= when passed on the command line. You need to set them for the invocation of configure, i.e. something like:
env CFLAGS=-m32 LDFLAGS=-m32 ./configure --disable-cxx
When this is done, all the symbols listed in the resulting lib/.libs/libconfig.a are listed with 32-bit addresses when the library is rebuilt.
Note in the configure script help output it does say:
Some influential environment variables:
which means that they need to be environment variables, not passed in as parameters to the command

How to configure a non-standard linker for an autotooled build?

I wanted to configure an autotooled project to invoke a non-standard
linker (the gold linker),
using the stock autotools of Linux Mint 16/Ubuntu 13.10
I believed I would achieve this by:
libtoolize-ing the project
Running ./configure LD=/path/to/my/linker ... etc.
However this has been ineffective. libtoolize has been successful. After
a standard ./configure; make I now see that libtool is doing the
linking:
/bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -o helloworld helloworld.o
But passing LD=/path/to/my/linker to configure makes no difference. Experimentally,
I even ran:
./configure LD=/does/not/exist
expecting to provoke an error, but I didn't. The output contains:
checking if the linker (/does/not/exist -m elf_x86_64) is GNU ld... no
checking whether the g++ linker (/does/not/exist -m elf_x86_64) supports shared libraries... yes
And thereafter a make continues to link, successfully, invoking g++ exactly as before.
What is the right way to configure a non-standard linker?
But passing LD=/path/to/my/linker to configure makes no difference
This is because LD is almost never and should almost never be used to link any user-space program. Correct links are performed by using the appropriate compiler driver (gcc, g++, etc) instead.
What is the right way to configure a non-standard linker?
If you have /some/path/ld and you want gcc to use that ld, pass -B/some/path flag to gcc.
It then follows that you likely want:
./configure CC='gcc -B/some/path' CXX='g++ -B/some/path' ...
I landed on this via a Google search, though my scenario is a bit different from yours; there was no libtool involved. An old open source program's Makefile was hard-coding ld to create an object file with a symbol from binary data.
This is what I ended up doing to work around the lack of $(LD) being recognized when passed to configure:
https://github.com/turboencabulator/tuxnes/commit/bab2747b175ee7f2fc3d9afb28d69d82db054b5e
Basically I added to configure.ac:
AC_CHECK_TOOL([LD], [ld])
Leaving this answer here for if someone else lands via a google search.

How to trace or debug GMP?

I have downloaded the source of GMP library 5.02, and - as suggested here for maximum debuggability - I ran :
./configure --disable-shared --enable-assert --enable-alloca=debug --host=none CFLAGS=-g
and compiled it with make, then installed the library with make install. I then compiled my program like this: gcc -lgmp -std=c99 -g -c program.c and then I ran : ltrace ./a.out
However I realized that ltrace is not at all invoking the TRACE() functions I can find in the source code. I would like to trace the content that's in TRACE().
How should I go for that? Or is there any other straightforward way of debugging inside the GMP library? (I couldn't figure it out how to do it with gdb, it never wanted to step into gmp_printf)
Thanks.
EDIT:
I tried to investigate further, and realized that I couldn't modify the GMP library although I had the sources. I inserted a printf("hello\n"); at the very beginning of the mpz_init2 function which I do call at the beginning of my program, I recompiled all GMP (even after a make clean) re-installed the library with make install, then I compiled and launched my program, but it never printed "hello". I also made sure, I wasn't using another installed GMP library (when I do make uninstall my program cannot compile as it does not find the library). Still, I insisted that gcc looks for the library in the GMP source folder with the -L option.
I don't know what I'm doing wrong :(
Your final compile of a.out is not producing a statically linked a.out executable. So, even though as you state, during compilation of program.c the compiler is using your GMP library, at runtime it is picking up a shared library somewhere. You need to do one of two things:
Compile with -Bstatic (or something similar; check man page for your compiler)
Set the LD_LIBRARY_PATH (or something similar; check 'ld' or 'dyld' man pages)
I think #1 is actually your only choice given that you built only the static version of GMP. For #1 make sure you explicitly provide -L/path/to/gmplib in the compilation of program.c

Resources