glibc fails with "get-dynamic-info.h:45: undefined reference to `_DYNAMIC'" - gcc

I was building gnu C/C++ compiler tools under windows 7 using Cygwin environment.
I am getting following errors while building the glibc . I have tried glibc 2.23 through glibc 2.30 sources.
During building all of them linker shows the same error : undefined reference to `_DYNAMIC'
I am trying to build a cross tool that will run under windows that will generate linux elf executables to run on the linux OS.
I was wondering if someone can help
I used bin utils 2.30 and 2.32
Linux headers 3.xx through 5.xx
Gcc 4.9.1 through 9.1.0
Glibc 2.23 through 2.30
target =i686-elf
DUMP from the screen
mv -f /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/rtld-libc.aT /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/rtld-libc.a
make[3]: Leaving directory '/home/RahmanA/src/gcc_port_4.9.1/glibc-2.23/elf'
i686-elf-gcc -nostdlib -nostartfiles -r -o /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os '-Wl,-(' /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/dl-allobjs.os /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/rtld-libc.a -lgcc '-Wl,-)' \
-Wl,-Map,/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os.map
i686-elf-gcc -nostdlib -nostartfiles -shared -o /home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/ld.so.new \
-Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \
/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os -Wl,--version-script=/home/RahmanA/src/gcc_port_4.9.1/build-glibc/ld.map \
-Wl,-soname=ld-linux.so.2 \
-Wl,-defsym=_begin=0
/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os: In function `elf_machine_load_address':
**/home/RahmanA/src/gcc_port_4.9.1/glibc-2.23/elf/../sysdeps/i386/dl-machine.h:58: undefined reference to `_DYNAMIC'
/home/RahmanA/src/gcc_port_4.9.1/build-glibc/elf/librtld.os: In function `elf_get_dynamic_info':
/home/RahmanA/src/gcc_port_4.9.1/glibc-2.23/elf/get-dynamic-info.h:45: undefined reference to `_DYNAMIC'**

Related

Not able to link static opencv library in C++ program on MAC OS

I have a c++ program using opencv libraries. I am able successfully to build my program on MAC OS using dynamic opencv libraries using the following command:
g++ -std=c++11 -Iinclude/ -o detect2 detect2.cpp -Llib3/ \
-lopencv_objdetect \
-lopencv_imgproc \
-lopencv_core \
-lopencv_videoio \
-lopencv_highgui
The above command generates the detect2 executable which works perfectly fine.
However, I want to statically link the opencv libraries so that later I can integrate this program into our MAC app so that we can distribute easliy without asking the user to install opencv on their MAC.
Following is the command I am using to build detect2.cpp using static opencv libs
g++ -std=c++11 -Iinclude/ -o detect2 detect2.cpp \
lib2/libopencv_objdetect.a \
lib2/libopencv_imgproc.a \
lib2/libopencv_core.a \
lib2/libopencv_videoio.a \
lib2/libopencv_highgui.a
But I get the following error:
ld: symbol(s) not found for architecture x86_64 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
If I use -static in the g++ command then I get
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Please let me know how can I build my cpp program with static opencv libs on MACOS. Thanks

Trouble building GCC 4.8.2: cannot find -lmpc

When I try to compile GCC 4.8.0 as a part of a greater system, in a custom directory. I have no sudo rights on this server and therefore I'm building everything from source. However, I can't get the dependencies gmp, mpfr and mpc to work. When running configure it gives me:
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations.
config.log gives me:
configure:5619: checking for the correct version of the gmp/mpfr/mpc libraries
configure:5650: gcc -o conftest -g -O2 -Wno-error=unused-value -I$SRC/gmp/ -I$SRC/mpc/src/.libs -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: cannot find -lmpc
collect2: ld returned 1 exit status
So I tried to get mpfr, gmp and mpc and build it manually from source, as I have no rights to install on the system itself. I ran ./contrib/download_prerequisites to get the libraries. I ran configure again, it gave me the same error. So I also compiled them and in my gcc dir I did:
cd mpfr; ./configure; make
cd ../gmp; ./configure; make
cd ../mpc; ./configure --with-mpfr-include=$SRC/mpfr --with-mpfr-lib=$SRC/mpfr/.libs/ --with-gmp=$SRC/gmp; make; cd ..
Note that just using --with-mpfr did not work for some reason.
cd $SRC/build
../configure \
--build=x86_64-linux-gnu \
CC=gcc \
CFLAGS='-g -O2 -Wno-error=unused-value' \
--disable-bootstrap --enable-checking=none \
--disable-multi-arch --disable-multilib \
--enable-languages=c,c++ \
--with-gmp-lib=$SRC/gmp/.libs \
--with-gmp-include=$SRC/gmp/ \
--with-mpc-include=$SRC/mpc/src \
--with-mpc=$SRC/mpc \
--with-mpfr-lib=$SRC/mpfr/.libs \
--with-mpfr-include=$SRC/mpfr \
--prefix=$SRC/prefix
where $SRC is my gcc directory. However, at the last command it gave me this error in the build/config.log:
gcc -o conftest -g -O2 -Wno-error=unused-value -I$SRC/gmp/ -I$SRC/mpfr -I$SRC/mpc/src conftest.c -L$SRC/gmp/.libs -L$SRC/mpfr/.libs -L$SRC/mpc/lib -lmpc -lmpfr -lgmp >&5
/usr/bin/ld: cannot find -lmpc
collect2: ld returned 1 exit status
It is obvious that after running make mpc does not have a lib directory, or anything containing shared object files. So I do not know how I have to link gcc with the mpc library.
Does anyone know what I should do?

Building 32 bit GCC from source on 64 bit: linking issue

/usr/bin/ld: i386:x86-64 architecture of input file `build/gengenrtl.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `build/errors.o' is incompatible with i386 output
/usr/bin/ld: build/gengenrtl.o: file class ELFCLASS64 incompatible with ELFCLASS32
/usr/bin/ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
I don't get if the problem is ld or the given library.
my configuration is
CC="gcc -m32" \
CFLAGS="-m32" \
LD="<path>/bin/32/binutils/2.23.2/bin/ld" \
LDFLAGS="-m32" \
./configure \
--build=i586-pc-linux-gnu \
--host=i586-pc-linux-gnu \
--target=i586-pc-linux-gnu \
--enable-shared \
--enable-static \
--enable-languages=c,c++ \
--enable-bootstrap \
--prefix=<path>/bin/32/gcc/i586 \
--disable-stage1-checking \
--with-gmp=<path>/lib/32/gmp/5.1.2 \
--with-mpfr=<path>/lib/32/mpfr/3.1.2 \
--with-mpc=<path>/lib/32/mpc/1.0.1 \
--with-cloog=<path>/lib/32/cloog/0.18.0 \
--without-ppl
Apparently I can't change the ld executable so easily, gcc keeps compiling with the global system /usr/bin/ld.
Someone can say what is going on here and how to fix this linking phase ?
I'm under Ubuntu 64 bit and I'm trying to compile a 32 bit build of gcc, of course I have already compiler gmp, mpc, mpfr for 32 bits.
Of course you can build gcc from source as 32-bit, using a 64-bit OS, compiler and linker. The problem is definitely not "ld".
You're doing exactly the right thing: specifying "-m32" in CFLAGS and LDFLAGS.
The problem is that build/gengenrtl.o and build/errors.o appear to have been built for 64-bit (instead of 32-bit).
SUGGESTIONS:
1) Check the makefile, and check your build log. See if there's anything "different" about the build commands for those two files.
2) Use the "nm" command to verify that the rest of your *.o object files were correctly built as 32-bit - that only "gengenrtl.o" and "errors.o" were (incorrectly) built as ELFCLASS64.
'Hope that helps...
I have solved similar problem (Compile gcc on amd64, for running on i686, and target is mips) with adding following to make command line:
CC="gcc -m32" CXX="g++ -m32" LDFLAGS=-m32
No need to specify full path to ld. But you forgot specify which C++ compiler to use.

How to install PyGSL? (Windows 7, 64 bit, Python 2.7, GSL 1.15)

I'm trying to install PyGSL on my computer (64 bit Windows 7), with Python 2.7 and GSL 1.15 installed. I'm pretty much stuck and I would love for some extra help. GSL installed fine, but its the wrapper that's the problem. For some reason I can't build pygsl. Apparently gcc is the problem (got the same problem on another windows machine). Or it could be that pygsl appears to be using a file named AMD64 while my computer is x86. I would love to use the windows binary for pygsl, but it only exists for python 2.5, and my project needs 2.6 or higher. I've used both the windows binary for GSL and built it from source, but I get the same problem either way. I tried copying dlls from GSL into pygsl but that didn't work. Some forums mentioned a file called gsl.dll but I can't seem to find it. I've also tried to use Cygwin and to compile with minGW32 to no avail.
cmds I ran:
python setup.py install
python setup.py build
python setup.py build_ext -i
python setup.py build --compiler=mingw32
Any ideas?? Thanks.
Cheers,
Bereket
Got the same message in Cygwin as in the windows cmd prompt. Error message:
$ /cygdrive/c/Python27/python.exe setup.py build_ext -i
numpy
Forcing DISTUTILS_USE_SDK=1
Building testing ufuncs!
running build_ext
building 'errno' extension
C compiler: gcc -g -DDEBUG -DMS_WIN64 -mno-cygwin -O0 -Wall -Wstrict-prototypes
compile options: '-DSWIG_COBJECT_TYPES=1 -DGSL_RANGE_CHECK=1 -DDEBUG=1 -DNUMERIC=0 -DPYGSL_GSL_MAJOR_VERSION=1 -DPYGSL_GSL_MINOR_VERSION=15 -UNDEBUG -IC:\Users\Bereket\gsl-1.15\include -IInclude -I. -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c'
gcc -g -DDEBUG -DMS_WIN64 -mno-cygwin -O0 -Wall -Wstrict-prototypes -DSWIG_COBJECT_TYPES=1 -DGSL_RANGE_CHECK=1 -DDEBUG=1 -DNUMERIC=0 -DPYGSL_GSL_MAJOR_VERSION=1 -DPYGSL_GSL_MINOR_VERSION=15 -UNDEBUG -IC:\Users\Bereket\gsl-1.15\include -IInclude -I. -IC:\Python27\lib\site-packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC -c src/init/errorno.c -o build\temp.win-amd64-2.7\Release\src\init\errorno.o
Found executable C:\cygwin\bin\gcc.exe
gcc -g -mno-cygwin -shared build\temp.win-amd64-2.7\Release\src\init\errorno.o -LC:\Users\Bereket\gsl-1.15\lib -LC:\Python27\libs -LC:\Python27\PCbuild\amd64 -lgsl -lgslcblas -lm -lpython27 -lmsvcr90 -o C:\Python27\Lib\pygsl-0.9.5\pygsl\errno.pyd
build\temp.win-amd64-2.7\Release\src\init\errorno.o: In function `add_errno':
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:14: undefined reference to `__imp__PyInt_FromLong'
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:20: undefined reference to `__imp__PyDict_SetItemString'
build\temp.win-amd64-2.7\Release\src\init\errorno.o: In function `initerrno':
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:37: undefined reference to `__imp__Py_InitModule4_64'
/cygdrive/c/Python27/Lib/pygsl-0.9.5/src/init/errorno.c:40: undefined reference to `__imp__PyModule_GetDict'
collect2: ld returned 1 exit status
error: Command "gcc -g -mno-cygwin -shared build\temp.win-amd64-2.7\Release\src\init\errorno.o -LC:\Users\Bereket\gsl-1.15\lib -LC:\Python27\libs -LC:\Python27\PCbuild\amd64 -lgsl -lgslcblas -lm -lpython27 -lmsvcr90 -o C:\Python27\Lib\pygsl-0.9.5\pygsl\errno.pyd" failed with exit status 1
I'm pretty sure now that my GSL install with Cygwin failed / had unresolved dependencies. I'm now trying to install it with visual studio 2010. Here are some good sites for doing that:
Instructions
Alt Method
Installing the Python 2.7 compiler for Windows is a good place to start
http://www.microsoft.com/en-gb/download/details.aspx?id=44266
Running python setup.py build_ext --inplace does the trick for me.
If this doesn't work let me know. You might need to add an environment variable.
Is your Python 32 or 64? To check open Python and do
import sys
sys.versions

Compiling LLVM 2.9's gcc 4.2 on kernel 3.0 with gcc 4.6

I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)

Resources