When trying to install the latest glibc into my machine provided I executed the "config" executable with flags: ../configure CFLAGS="-O3 -fPIC" --disable-sanity-checks it generates the makefile correctly, although I think disable-sanity-checks will give some errors.
But whenever I try to execute the generated Makefile using make, the console prints the following error:
make[3]: Leaving directory '/mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/elf'
gcc -nostdlib -nostartfiles -shared -o /mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/glibc-build/elf/ld.so.new \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \
/mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/glibc-build/elf/librtld.os -Wl,--version-script=/mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/glibc-build/ld.map
\
-Wl,-soname=ld-linux-x86-64.so.2 \
-Wl,-defsym=_begin=0
/mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/glibc-build/elf/librtld.os: In function `process_envvars':
/mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/elf/rtld.c:2686: undefined reference to `__GI___open64_nocancel'
/usr/bin/ld: /mnt/c/Users/SCP173/Downloads/Thread/glib/glibc/glibc-build/elf/librtld.os: relocation R_X86_64_PC32 against undefined symbol `__GI___open64_nocancel' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
As I said, I tried to add the -fPIC flag but still didn't catch it. And I'm kind of new to .os, .map and other extensions such as those. Am I doing it completely wrong? Or else, how could I compile just that file using gcc instead of passing the flag to the whole make command?
Your file system is not set up correctly. By default, NTFS is case-preserving, but case-insensitive. As far as I understand it, current versions of WSL set up only part of the file system tree in case-sensitive mode. (A previous system-wide configuration is now disregarded.)
Building glibc requires a case-sensitive file system. Please also note that WSL is not a proper development environment for glibc because there are so many test failures due to bugs in the WSL kernel emulation.
Related
I am trying to compile a program within a docker container built from the Alpine 3.7 base image. The program uses argp.h, and includes it as #include <argp.h>. I have installed argp-standalone and verified that it is making it onto the image. The file argp.h is located in usr/include, however when I compile my program using the following commands:
gcc -W -Wall -Wextra -I/usr/include -c -o progname.o progname.c
gcc -largp -o progname progname.o
I get the following error:
progname.o: In function `parse_opt':
progname.c:(.text+0x4c9): undefined reference to `argp_failure'
progname.c:(.text+0x50f): undefined reference to `argp_failure'
progname.c:(.text+0x555): undefined reference to `argp_failure'
progname.c:(.text+0x59b): undefined reference to `argp_failure'
progname.c:(.text+0x5ce): undefined reference to `argp_error'
progname.c:(.text+0x5f4): undefined reference to `argp_error'
progname.o: In function `main':
progname.c:(.text+0x1397): undefined reference to `argp_parse'
collect2: error: ld returned 1 exit status
make: *** [Makefile:9: progname] Error 1
I have:
Ensured that the version of argp.h which is on the image does in fact include the argp_failure, argp_parse, and argp_error functions.
Tried moving argp.h into different locations on the machine (e.g. into the same directory where compilation is taking place, into /usr/lib)
Tried compiling with -l and -L.
The relevant packages also installed in the image are build-base, make, and gcc.
When compiling on an Ubuntu image these same commands work fine, even without the -largp and -I/usr/include flags. What could be happening differently within an Alpine image which would cause this not to work?
Edit
As per #Pablo's comment, I'm now compiling it as follows:
gcc -W -Wall -Wextra -I/usr/include -L/usr/lib -c -o progname.o progname.c
gcc -largp -o progname progname.o
After having verified that the static library, libargp.a, is located in /usr/lib. However, the same problem still persists.
Edit 2
Compiling as follows (and once again as per #Pablo's suggestion) has resolved the error I was having:
gcc -W -Wall -Wextra -I/usr/include -L/usr/lib -c -o progname.o progname.c
gcc -o progname progname.o /usr/lib/libargp.a
However, I am still curious why, using the exact same library and instructions, this would fail to compile in an Alpine image while compiling without issue in an Ubuntu image.
I am still curious why, using the exact same library and instructions, this would fail to compile in an Alpine image while compiling without issue in an Ubuntu image.
The reason for the linking error on Alpine may be kind of surprising, and is actually not specific to Alpine.
While this fails to link:
gcc -largp -o progname progname.o
This works:
gcc -o progname progname.o -largp
The reason is the order of parameters passed to the linker, and it related to the linking algorithm. Typically, in the linking command line objects are specified first (and possibly user's static libraries in any), then libraries using -l. The standard linker algorithm is explained perfectly in Eli Bendersky's article, Library order in static linking:
Object files and libraries are provided in a certain order on the command-line, from left to right. This is the linking order. Here's what the linker does:
The linker maintains a symbol table. This symbol table does a bunch of things, but among them is keeping two lists:
A list of symbols exported by all the objects and libraries encountered so far.
A list of undefined symbols that the encountered objects and libraries requested to import and were not found yet.
When the linker encounters a new object file, it looks at:
The symbols it exports: these are added to the list of exported symbols mentioned above. If any symbol is in the undefined list, it's removed from there because it has now been found. If any symbol has already been in the exported list, we get a "multiple definition" error: two different objects export the same symbol and the linker is confused.
The symbols it imports: these are added to the list of undefined symbols, unless they can be found in the list of exported symbols.
When the linker encounters a new library, things are a bit more interesting. The linker goes over all the objects in the library. For each one, it first looks at the symbols it exports.
If any of the symbols it exports are on the undefined list, the object is added to the link and the next step is executed. Otherwise, the next step is skipped.
If the object has been added to the link, it's treated as described above - its undefined and exported symbols get added to the symbol table.
Finally, if any of the objects in the library has been included in the link, the library is rescanned again - it's possible that symbols imported by the included object can be found in other objects within the same library.
When -largp appears first, the linker does not include any of its objects in the linking procedure, since it doesn't have any undefined symbols yet. If the static library is provided by path, and not with -l, then all of its objects are added to the linking procedure.
I'm trying to install AODV protocol on Raspberry pi. After completing git clone from "https://github.com/erimatnor/aodv-uu" when I tried to do "make" and I am getting below error. Expecting your suggestion. Thank you!
make
gcc -Wall -O3 -g -DDEBUG -DCONFIG_GATEWAY -DDEBUG -o aodvd main.o list.o debug.o timer_queue.o aodv_socket.o aodv_hello.o aodv_neighbor.o aodv_timeout.o routing_table.o seek_list.o aodv_rreq.o aodv_rrep.o aodv_rerr.o nl.o locality.o
aodv_neighbor.o: In function neighbor_add':
/home/pi/aodv-uu/aodv_neighbor.c:68: undefined reference tohello_update_timeout'
aodv_timeout.o: In function route_discovery_timeout':
/home/pi/aodv-uu/aodv_timeout.c:98: undefined reference tort_table_update_timeout'
aodv_rreq.o: In function rreq_route_discovery':
/home/pi/aodv-uu/aodv_rreq.c:460: undefined reference tort_table_update_timeout'
aodv_rreq.o: In function rreq_local_repair':
/home/pi/aodv-uu/aodv_rreq.c:521: undefined reference tort_table_update_timeout'
aodv_rrep.o: In function rrep_forward':
/home/pi/aodv-uu/aodv_rrep.c:231: undefined reference tort_table_update_timeout'
nl.o: In function nl_kaodv_callback':
/home/pi/aodv-uu/nl.c:282: undefined reference tort_table_update_timeout'
collect2: error: ld returned 1 exit status
Makefile:112: recipe for target 'aodvd' failed
make: *** [aodvd] Error 1
The code available from sourceforge is the same code that is on github. If you download the archive, you'll see that the latest modification date of any file there is 2010. Given the age of this code, I wouldn't be surprised to find that things simply don't work anymore.
However, here's a quick workaround for your problem. The root cause appears to be that the problem functions, like rt_table_update_timeout, are declared as inline, but that information seems to get lost somewhere in the build process such that other object files are trying to reference these as non-inline functions.
You can avoid this by opening defs.h, looking for this line:
#define NS_INLINE inline
And replace it with:
#define NS_INLINE
This will allow aodvd to compile correctly (make aodvd). On my system, the kernel module will subsequently fail to compile:
cc1: fatal error: /lib/modules/4.13.15-100.fc25.x86_64/build/include/linux/modversions.h: No such file or directory
As far as I can tell, the modversions.h file is no longer produced by modern Linux kernels.
I am working with c++ code for a physics simulation, which uses a lot of external libraries (like GSL and cern`s ROOT). Trying to recompile project I encountered problems with linking. When running compilation of final file via:
g++ -fno-inline -O2 -fpic -o main.out ${ROOTINCS} main.o ext.o ${ROOTLIBS} $(objects2)
with :
objects2= many .o files made by us
ROOTLIBS=-L/usr/local/lib/root -lTree -lRIO -lNet -lHist -lMathCore -lCore -lGraf -lGraf3d -lGpad -lMatrix -lThread -lCint -lPhysics -lPostscript -lRint -lSpectrum -lg
ROOTINCS=-pthread -m64
I get annoying error:
/usr/bin/ld: /usr/local/lib/root/libHist.so: undefined reference to symbol 'gRandom'
/usr/local/lib/root/libMathCore.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The problem is nm -C run on libMathCore states 'gRandom' is declared there. Also -lMathCore is present in my command line.
When I run ld to check if it understands the flag:
ld -L/usr/local/lib/root -lMathCore --verbose 2>/dev/null
it does not complain and tries to link properly.
According to https://stackoverflow.com/a/24675715/3602168 order of libraries is correct in my linking (libHist uses libMathCOre and therefore is stated first).
Compilation runs under g++ 4.8.2 on ubuntu 14.04, 64 bit
Converting comment to answer:
Have you tried moving $(objects2) before ${ROOTLIBS}? I think the issue may be that you have libraries specified before the object files that use them.
I'm trying to compile a makefile which includes the following line:
gcc -I. -I/home/usr/Documents/MTV/include -ggdb3 -Wall -O2 -o ascii2bin.c \
-L. -L../lib -lmatrix -lseq_io -lpic -lm
And this is what I get:
../lib/libmatrix.a: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Any idea on what might happen to libmatrix.a? How can I read what's inside libmatrix.a? I tried using the 'ar -t' command, but it also says file format not recognized.
The project was compiled on Cygwin before by others, and now I'm using ubuntu gcc to try to redo it, could this be the problem?
A library file built for cygwin will not work on linux.
The library itself must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which it is intended to be used.
Cygwin tries to be source compatible with Linux, so if you have the source rebuilding may be straightforward. But it is not binary-compatible, and libraries are basically binary building blocks with metadata to permit linking them together.
I'm trying to build a project for ARM uClibc environment, but I've some functions missing. Can not find which library shall I include to resolve dependancies. nm do not help me to search, since it says on most of libs coming with toolchain:
nm: ./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/libuClibc-0.9.32.1.so: no symbols
Here is the output from GCC:
./host/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc
-Wl,-rpath,./host/usr/lib/
-Wl,-rpath,./host/usr/../lib/
-Wl,-rpath,./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-Llibzway -o test_so main.o -lzway
-L./host/usr/lib/
-L./host/usr/../lib/
-L./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/ -lpthread
-lxml2 -lz -lm
./host/usr/lib/libxml2.so: warning: gethostbyname is obsolescent, use getnameinfo() instead.
./host/usr/lib/libxml2.so: undefined reference to `fcntl64'
./host/usr/lib/libxml2.so: undefined reference to `fopen64'
./host/usr/../lib/libz.so: undefined reference to `lseek64'
./host/usr/lib/libxml2.so: undefined reference to `stat64'
./host/usr/lib/libiconv.so.2: undefined reference to `mbrtowc'
./host/usr/lib/libiconv.so.2: undefined reference to `_stdlib_mb_cur_max'
./host/usr/lib/libiconv.so.2: undefined reference to `wcrtomb'
./host/usr/lib/libxml2.so: undefined reference to `open64'
collect2: ld returned 1 exit status
make: *** [test_so] Error 1
UPD:
I've copied uClibc from the target host and explicitely defined asked to link with it:
./host/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc
-Wl,-rpath,./host/usr/lib/
-Wl,-rpath,./host/usr/../lib/
-Wl,-rpath,./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-Llibzway -o test_so main.o -lzway
-L./host/usr/lib/
-L./host/usr/../lib/
-L./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-luClibc-0.9.31
-lpthread -lxml2 -lz -lm
./host/usr/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.5.3/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld:
errno: TLS reference in ./host/usr/bin/../arm-unknown-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0 mismatches non-TLS definition in ./host/usr/lib/libuClibc-0.9.31.so section .bss
./host/usr/bin/../arm-unknown-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [test_so] Error 1
This is much bayond my knowledge of cross-compilation. Any idea?
It sounds like you have several issues going on:
You seem to be trying to use the host's copy of libxml2.so. This is not going to work. You need one built for your target system and its libc.
Your uClibc was compiled without large file support. Go back and fix the build options or uClibc. It's not strictly necessary (a correctly built libxml2.so linked against uClibc will work without doing this), but using the pre-large-file interfaces is really backwards and will unnecessarily limit your programs.