I am having an issue that I believe is the result of compiler versions. I have three external libraries, we will call liba, libb, and libc. All of the libraries compiled without any issues using ifort 11.1 on Redhat Linux 5.3. This is the snippet of code from the makefile, which works just fine:
foo.exe: foo.o
ifort -m64 foo.o liba libb libc -o $#
I am trying to move the code to a new system, which is using ifort 16.0.2 on Redhat Linux 6.7. The makefiles for the external libraries work without any modification. However, when I go to compile the executable using the same code shown above, I get multiple undefined reference errors.
My guess is that there is an environmental variable I need to modify or a compiler/linker option that I need to add, but I am unsure where to go from here.
Related
For example, consider that I wrote a Fortran program in one computer and want to run it on another computer which may not have required libraries and/or has a different compiler (or even better, no Fortran compiler at all). Is it possible to create an executable with all its dependencies?
I am using gfortran (7.2.1) in Fedora 26 and sometimes use LAPACK routines in my code.
Using -static option with the program
program main
write (*,*) 'Hello'
end
I get the output
gfortran -static a.f90
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
There is no error with gfortran -static-libgfortran a.f90
In Fedora, gcc does not ship by default with static libraries.
You need to install the package glibc-static for the -static option to work, as hinted in this related question.
Note that -static-libgfortran will only do static linking of the libgfortran library and that you must have static versions of your dependencies as well.
The best option is to use Alpine Linux that uses musl libc. I highly recommend using the docker image (only 5 Mb).
Question
I want to override/clear g++ default search path for libraries, so that g++ does only search libraries under paths explicitly specified:
$ arm-linux-gnueabihf-g++ --print-search-dirs | grep libraries:
libraries: =/usr/lib/gcc-cross/arm-linux-gnueabihf/6/:/usr/lib/gcc-cross/arm-lin
ux-gnueabihf/6/../../../../arm-linux-gnueabihf/lib/arm-linux-gnueabihf/6/:/usr/l
ib/gcc-cross/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/lib/arm-linux
-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/6/../../../../arm-linux-gnuea
bihf/lib/../lib/:/lib/arm-linux-gnueabihf/6/:/lib/arm-linux-gnueabihf/:/lib/../l
ib/:/usr/lib/arm-linux-gnueabihf/6/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/../li
b/:/usr/lib/gcc-cross/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/lib/
:/lib/:/usr/lib/
Can this be done?
Background
I'm on Ubuntu 17.04 compiling c++ code for several cross-platform distributions.
I've installed Ubuntu g++-arm-linux-gnueabihf package, and created a target image under /opt/jessie_root, in this case for Jessie armhf. I also fixed all the links under this jessie_root image to be relative and not absolute.
I want to compile dynamic executables with the target rootfs libraries.
Initially I was compiling "fine" but I realized that I was linking to symbols on the host cross-toolchain libstdc++.
I'm using cmake, but for simplicity consider this commands:
/usr/bin/arm-linux-gnueabihf-g++ main.c
This will link to the host libstdc++ under /usr/lib/gcc-cross/arm-linux-gnueabihf/6/libstdc++.so, which is not desirable.
/usr/bin/arm-linux-gnueabihf-g++ main.cpp --sysroot=/opt/jessie_root -L=/usr/lib/gcc/arm-linux-gnueabihf/4.9 -D_GLIBCXX_USE_CXX11_ABI=0
This will link correctly to the target libstdc++ under /opt/jessie_root/usr/lib/gcc/arm-linux-gnueabihf/4.9/libstdc++.so, which I want.
The issue is that this seems a disaster waiting to happen, as if one of the default libs are not found on the target, the compiler will haply take one from the host cross-toolchain.
I could remove or rename them, but I don't want to mess on /usr/.
I have also played with GCC -nostdlib and LD -nostdlib, which seem to have different meanings. GCC -nostdlib is for libraries, and LD -nostdlib is for the search directories. LD -nostdlib have no effect, and GCC -nostdlib just forces me to specify the libraries manually, but it still keeps the search paths.
Naturally I could use another toolchain/compile my own, but I would prefer to stay on the packaged toolchain.
I would like to prepare GNU toolchain for bare metal ARM to use it with Geany IDE. There are some tutorials like this one: Building the GNU ARM Toolchain for Bare Metal but I do not understand few steps.
First of all, everyone who uses Linux OS implicitly has gcc, binutils and gdb so why to download others? Secondly all tutorials tell me to configure gcc with something like that: *./configure --target=arm-elf. What does it even do ? Does it just force me to call gcc in command line using arm-elf-gcc instead of gcc or does it change some internal options of my gcc ?
So far I have prepared makefile but I am still not sure about compiler options. I have not changed any gcc configure options and I call compiler with such flags:
CFLAGS = -Wall -std=c99 -march=armv7-m -mtune=cortex-m0
Can I prepare toolchain just with calling gcc with proper arguments or do I need to make some changes in gcc configuration ?
GCC and its target
GCC is always configured to emit binaries for a specific target. So normally the gcc which is already available on Linux has the target "i486-linux-gnu". You can't cross-compile to an ARM target using this compiler.
So you need to install another GCC configured for that target; then GCC and the other programs normally have a prefix indicating the target: In your case the prefix is arm-none-eabi, and then you call that GCC using arm-none-eabi-gcc. You can have multiple GCC installations, they do not interact (if they interact, you have probably screwed up something - always install in separate directories, if you do it manually).
Installing
If your Linux distribution provides a package, you could just install that one (on Debian this is "gcc-arm-none-eabi").
You can download a pre-compiled package: GNU Tools for ARM Embedded Processors.
You can try to compile one. Not really easy, if you want correct multi-libs.
If your Linux distribution provides a package > 4.8.0, you should try that one.
If you want to have multiple versions installed (and be able to switch between them easily), the second option is possibly better. I stopped compiling a GCC for ARM when the second option was available.
Cross-compiling
In your Makefile you have to make sure that the cross-compiler is used. You could use $(CC) in your Makefile, and assign it like this:
TOOLCHAIN = arm-none-eabi-
CC = $(TOOLCHAIN)gcc
Compiler flags for Cortex-M0 are -mcpu=cortex-m0 -mthumb -mfloat-abi=soft which is by convention assigned to CFLAGS
CFLAGS += -mcpu=cortex-m0 -mthumb -mfloat-abi=soft
Then a (simple) rule to compile .c to .o looks like
%.o: %.c
$(CC) $(CFLAGS) -o $# -c $<
Tutorials which use the arm-elf- prefix are out-dated. Currently arm-none-eabi- is in use.
i am trying to build a custom version of the linux kernel 3.8 and i want my linker to behave a bit different so i changed its ldscripts.
Specifically I configure binutils -> make -> change ldscripts -> make install.
However when i try to compile libc using my linker the only thing i see is this :
GNU ld (GNU Binutils) 2.23
Supported emulations:
elf32_sparc
sparclinux
elf64_sparc
sun4
using internal linker script:
==================================================
/* Script for --shared -z combreloc: shared library, combine & sort relocs */
etc
The thing is that i have changed my ldscripts and prepended a tag at the beginning of each script in order to recognize them but my compiler does not seem to care.
However i don't have any other elf scripts in my system so the option of searching the wrong library path is not actually an option.
Is there something i am missing here?
Notice that i am cross compiling for sparc
You can pass a custom linker script to ld:
ld -T <path/to/file> ...
or to gcc:
gcc -Wl,-T,<path/tofile> ...
Default ld scripts get compiled into compiler driver (gcc) so you should at least rebuild the toolchain.
That's also probably the case that gcc will not look at any linker scripts other than built into it, so you'll have to modify them in toolchain (it's probably in spec files somewhere).
This question already has answers here:
How to link to a shared library without lib* prefix in a different directory? [duplicate]
(2 answers)
Closed 2 years ago.
I compiled a few libraries using Eclipse-CDT on windows. However, when I tried to compile them under linux gcc keeps giving me the error /usr/bin/ld: cannot find -lrequestedLib. I'm using the exact same build settings between the two environments (namely I made sure to add the directories that contain the libraries i need to link to). I'm sure the system has read access rights to the files as well. I'm not sure what to make of this. Please help.
Edit: These are the commands that ecplise runs to build the library:
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
Edit 2: The command that renders the error is the second of the two, resulting in the /usr/bin/ld: cannot find -lrequestedLib being output.
Edit 3: I've confirmed that requestedLib.so is a x86_64 binary.
If you don't want to pass -L command line options to gcc(1), be sure to add the path containing the libraries to /etc/ld.so.conf or /etc/ld.so.cond.d/<something>.
Once you've installed your libraries you also need to run ldconfig(8) by hand. (Most new users forget this step because typical package managers take care of this for you when installing new libraries.)
gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib
When building 64-bit shared libraries on x86_64, the -fPIC flag is usually required, or you get a recompile with -fPIC error at shared library link time.
Since you didn't use -fPIC, yet your link succeeded, you are likely using (non-default) gcc that targets i*86 (that is, produces 32-bit output). You can confirm that by running file libToMake.so.
You didn't show that command that actually fails (the one that produces cannot find -lrequestedLib error). I am guessing that that command is using a different gcc (default one?), that targets x86_64. If it looks something like
gcc main.c -L/home/me/lib -lrequestedLib
that command will ignore /home/me/lib/librequestedLib.so (because you can't link together 32-bit and 64-bit code), and will continue searching for librequestedLib elsewhere. When it can't find a 64-bit version of librequestedLib, it will produce the error message you are gettiing.