I am trying to write a single CMakeLists.txt file for C++ compilation on Linux with G++ and on OSX with Clang.
I want to use the Target Library flags -Wl,--start-group and -Wl,--end-group with G++, but these give an error when linking with Clang: ld: unknown option: --start-group
The only results I can find choose to just delete these flags on Mac copies, but that doesn't allow easy project migration from linux to OSX. I tried to make these statements CMAKE conditions, but those are treated as literal libraries which are not found:
eg: $<IF($<NOT:APPLE>)> -Wl,--start-group $<ENDIF($<NOT:APPLE>)>
produces: c++: error: $<IF: No such file or directory
Is there a way to conditionally edit in the CMAKE TARGET_LINK_LIBRARIES field?
I'd try this:
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
set(START_GROUP "-Wl,--start-group")
set(END_GROUP "-Wl,--end-group")
else()
set(START_GROUP "")
set(END_GROUP "")
endif()
Then just replace those options with ${START_GROUP} and ${END_GROUP}, and they will only be used with the GNU compiler.
Don't switch based on platform if it's really the compiler that matters. Otherwise, Clang users on Linux won't be able to build your project.
Related
I am trying to add alsa library to my Eclipse in order to cross-compile and debug in my iMX8X.
I have cross compiled the alsa-lib by
./configure --host=aarch64-unknown-linux-gnu --with-pcap=linux
I have added the library path where my libasound.so is in properties-> Cross GCC Linker -> libraries (search path), in my case /usr/lib, this is built
aarch64-linux-gnu-gcc -pthread -L/usr/lib -lasound -o "test1.elf" ./src/test1.o
but this error appears in my console and I dont know how to fix it,
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: no se puede encontrar -lasound
Should I try to compile alsa-utils, firmware, ...?
Or how can I debug this in order to use alsa snd_pcm functions?
Do I have to add some more files to the library definition?(like libasound.la or libasound.a)
Thanks in advance.
I have created an Ubuntu 20.04 Virtual Box image, compiled there alsa-lib, alsa-utils and alsa-tools libraries. I installed eclipse and link all the libraries in my linker. I managed to compile it by adding -L/usr/lib and -lasound again, deleting the previous one. Make sure where the compilation of your library is and link it in the Cross GCC Linker -> Libraries in a path, which in my case was /usr/lib. No idea why the previous one didnt work.
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'm trying to build a package on lauchpad. For it to build I need to set a static path using the LDADD variable in automake:
relay_LDADD = /usr/lib/x86_64-linux-gnu/libm.so /usr/lib/x86_64-linux-gnu/libX11.so.6 $(RELAY_LIBS)
This compiles on the 64 bit build but fails on the 32 bit build. I tried using PKG_CHECK_MODULES but it says
No package 'm' found
No package 'X11' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
I know it not a non standard path since launchpad is doing the building? How can I get this to work?
The build failed without the libraries specified even though the package specifies them in the build-requires.
You have tried to outwit the buid-system, and it has outwitted you.
It's generally a bad idea to hard-code paths.
Debian (and ubuntu is just a derivative), has started to ship binaries (like libraries) in architecture-dependent directories, to allow installations for multiple architectures on a single system.
These libraries are installed into /usr/lib/<host-triplet>, where <host-triplet> depends on the architecture; e.g. x86_64-linux-gnu is the amd64 architecture for systems with a linux and the gnu tools.
a 32bit system would typically have a host-triplet of i386-linux-gnu.
Since you are hard-coding the library path to a 64bit location( /usr/lib/x86_64-linux-gnu/libm.so) this fails on all systems but 64bit/linux/gnu.
Instead you should just tell the linker to link against the m library (libm), resp the X11 library (libX11).
Let the linker care for the correct architecture to pick:
relay_LDADD = -lm -lX11 $(RELAY_LIBS)
In general, if you want to link against a library foo, that provides a library-file libfoo.so you would use -lfoo (stripping away the leading lib and the trailing .so).
However, sometimes this is not enough; in those cases your library might use pkg-config to provide the full CFLAGS and LDFLAGS needed to compile/link against this library.
e.g. if I want to use libquicktime:
$ pkg-config --cflags libquicktime
-I/usr/include/lqt
$ pkg-config --libs libquicktime
-lquicktime -lpthread -lm -lz -ldl
So I would use something like:
myprog_CFLAGS += $(shell pkg-config --cflags libquicktime)
myprog_LDADD += $(shell pkg-config --libs libquicktime)
That would work in any GNU(?) Makefile (not related to autotools).
In an autotools project, you would probably move the pkg-config check into configure, using the m4-macro PKG_CHECK_MODULES
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).
I'm trying to make a cross compiler with the files from http://crossgcc.rts-software.org/doku.php?id=i386linuxgccformac
I'm on an Intel Mac (10.6.6, x86_64) I compiled: gmp, mpfr, mpc for the cross compiler as 32bit (as I'm on a 64bit Mac) but I'm getting
ld: warning: option -s is obsolete and being ignored
ld: warning: ignoring file /gmp1/lib/libmpc.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: ignoring file /gmp1/lib/libmpfr.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: ignoring file /gmp1/lib/libgmp.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
When compiling GCC with:
--prefix=/usr/local/i386-linux-4.5.2 --target=i386-linux --enable-languages=c --without-headers --disable-shared --disable-threads --disable-nls --with-gmp=/gmp1 --with-gmp-lib=/gmp1 --with-gmp-include=/gmp1 --with-mpfr=/gmp1 --with-mpfr-include=/gmp1 --with-mpfr-lib=/gmp1 --with-mpc=/gmp1 --with-mpc-lib=/gmp1 --with-mpc-include=/gmp1
Also, if I compile GMP with:
./configure --prefix=/gmp1 --host=i386-linux
I get:
configure: WARNING: +----------------------------------------------------------
configure: WARNING: | Cannot determine global symbol prefix.
configure: WARNING: | link -dump -symbols output doesn't contain a global data symbol.
configure: WARNING: | Will proceed with no underscore.
configure: WARNING: | If this is wrong then you'll get link errors referring
configure: WARNING: | to ___gmpn_add_n (note three underscores).
configure: WARNING: | In this case do a fresh build with an override,
configure: WARNING: | ./configure gmp_cv_asm_underscore=yes
configure: WARNING: +----------------------------------------------------------
checking how to switch to read-only data section... .data
checking for assembler .type directive...
checking for assembler .size directive...
checking for assembler local label prefix... configure: WARNING: "link -dump -symbols" failure
configure: WARNING: cannot determine local label, using default L
L
checking for assembler byte directive... .byte
checking how to define a 32-bit word... link: illegal option -- d
I think that you are confused about which package should be compiled for which platform:
GCC needs to be compiled for an x86_64 MacOS X host and an i386-linux target.
GMP, MPC and MPFR are runtime dependencies for GCC. Therefore they also need to be compiled for the GCC host - x86_64 in your case. Therefore, the --host=i386-linux option in the GMP configure command is incorrect.
In general, only libraries that will be linked in the programs compiled by GCC need to be built for the cross-compiler target (e.g. i386-linux). GMP and MPFR are not such libraries, unless your programs are actually using them - in that case you will need to have two copies of such libraries, one for GCC and a cross-build for the target.
EDIT:
Have you considered using MacPorts? It has all the dependencies for your cross-compiler:
gmp-5.0.1
mpfr-3.0.0
libmpc-0.8.2
There is also an older newlib-based cross-compiler for i386:
i386-elf-gcc-4.3.2
Even if you do not want to use these, you can still have a look at the build instructions in their Portfiles.
The bottom line is:
Apply whatever patches these libraries need - MacPorts already do that.
Compile the libraries for your build host i.e. MacOSX/x86_64. That means that in any --host options for their configure calls you should be something along the lines of --host=x86_64-darwin (or whatever your host needs). If configure can figure out the host on its own, you can skip the --host options altogether.
Compile GCC with --host being your build host (the 64-bit Mac OS X) and a target of i386-linux, e.g. --target=i386-linux. If I were you, I'd start simple with a compiler for the C and C++ languages only.
See also this tutorial. It has some information on how to produce a working toolchain with a proper glibc.
That said, I think that you'd be better off installing a proper Linux distribution in a virtual machine, for a whole bunch of reasons. Is there a reason for you to need a cross-compiler specifically? What do you want to do with that compiler?
Did you use the "ABI=32" option when compiling GMP? If not, I think it will use 64-bit code even if the host/target are specified as i386.