I want to build a Qt project using either GCC or an ARM compiler. In either environment I have to link different libraries.
How I can check if the current compiler is Linux's g++ and CROSS_COMPILE is 'arm-cortexa9neont-linux-gnueabi-'?
You can use the Platform Scope built in to QMake to set up the build differently depending on platform.
It's based on the mkspec's shipped with Qt and can be found in
[Where Qt's installed]/mkspecs
So in your case I guess it'll look something like this:
linux-arm-gnueabi {
//ARM stuff here
}
Please note that I have not tested this. I've only read what's in the documentation I have linked to.
If you want to know only type of processor, you can use Q_PROCESSOR_ARM macro.
Related
According to various guides on cross-compiling Rust I need to set something like this in .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
In my case I am cross compiling for Linux on Mac. This is fine, but I'd also like to be able to build the code natively on Linux (i.e. not cross-compiling). In that case surely the target is still x86_64-unknown-linux-musl, but I don't want to override linker then.
I guess you can probably do this using a custom build.rs, but is there any way to do this from .cargo/config? I thought you'd be able to do something like this:
[target.'cfg(all(host_os = "macos", target_os = "linux"))']
linker = "x86_64-linux-musl-gcc"
But there is no host_os.
I'm guessing that you've put .cargo/config inside of your Cargo workspace?
If this the case, you should consider moving host-specific configuration options (such as target.{target}.linker) into your user-specific ~/.cargo/config instead. That way, the linker is not tied to the workspace configuration, but instead to the user: different users on different hosts could have different linkers configured for different targets.
I'm compiling dalvik on Android 4.1 with both host and target set to x86. The make command is:
make dalvikvm core ext framework android.policy services
However, there are multiple compiled binaries:
out/host/linux-x86/bin/dalvikvm
out/host/linux-x86/bin/dalvik
out/target/product/generic_x86/system/bin/dalvikvm
out/target/product/generic_x86/symbols/system/bin/dalvikvm
But the target versions don't work. When run, they show:
bash: ./dalvikvm: No such file or directory
This error is so strange that, I mean, the file is just there.
Could anyone please tell me which one is the compiled result? I mean, if I make some modification to dalvik source, which one will contain the modified result? Thank you.
This is almost certainly a linkage issue. The host version is linked against the normal host libc, but the target versions are linked against the android libc that lives in /system/lib on the device, which your host ld knows nothing about.
You might try something like:
LD_LIBRARY_PATH=<android_root>/out/target/product/generic_x86/system/lib out/target/product/generic_x86/symbols/system/bin/dalvikvm
Although I'm not entirely sure if that would work
I'm trying to build my application with MSVC 2010 instead of GCC. With GCC everything works fine. My app uses boost_system and boost_thread libraries.
I built boost with VC2010 in "system" layout, that means the libraries are named just libboost_system.lib (and not libboost_system_compiler_threading_version_wtf_snafu.lib)
The libs reside in C:\Boost\lib,
the Makefile specifies
LFLAGS = /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:CONSOLE
LIBS = /LIBPATH:C:/Boost/lib libboost_system.lib libboost_thread.lib Ws2_32.lib
when invoking nmake it compiles, but when trying to link it quits with
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-1_43.lib
I mean seriously, WTF? I told it to link libboost_systen.lib and libboost_thread.lib how come it tries to link libboost_data_time and why does it assume I built the libs in "tagged" layout??
How can I stop MSVC trying to be smart and guess what I might have wanted to link?
Thanks,
Philipp
This is a feature of the Boost libs with compatible compilers for automatic linking.
(Those convoluted library names cover the myriad of threading and linking options that are available on the platform; there are good reasons to use that convention on Windows...)
More information here:
http://www.boost.org/doc/libs/1_33_1/more/getting_started.html#auto-link
I can't find a page for a more recent version, but I believe the BOOST_ALL_NO_LIB and related options are all still valid in 1.43.
Assuming you are auto-linking (i.e. you've defined BOOST_ALL_DYN_LINK or library specific equivalents).
For layout 'system' you have to define the preprocessor macro:
BOOST_AUTO_LINK_NOMANGLE
to link to the correct library names.
For layout 'tagged' you have to define the preprocessor macro:
BOOST_AUTO_LINK_TAGGED
to link to the correct library names.
I don't know if you could do this override for some libraries and keep the default for others. That would be a very cumbersome setup I'd imagine.
How can I force automake to create a standard shared library, instead of a libtoolized one? Normally, I'd create the abc.so which is referenced with a full path and loaded into the main program. Is there a way to force AM to do the same? If I list it as _LIBRARY, automake complains: 'abc.so' is not a standard library name; did you mean 'libabc.a'
Just to clarify: Yes, I only need .so support - no statics. And yes, I want a custom file name.
libtool is the way to go. If you want a custom name, add the -module option to _LDFLAGS, for example:
plugindir= /some/where
plugin_LTLIBRARIES= abc.la
abc_la_LDFLAGS= -module
Automake does not know how to build a shared library because there is no portable way to do so. If you want a shared library with Automake, you have to use Automake+Libtool. Note that you can easily configure libtool not to build any static library (with LT_INIT([disable-static]) in your configure.ac) by default.
A libtoolized library is a wrapper around one or more standard libraries.
You can find these libraries in ".libs" after running "make", or in "$prefix/lib" after running "make install".
On a Linux machine, you should find eventually a file called "libabc.so".
IIRC, there is nothing special about libraries created with the help of libtool, unless you link against libltdl. If you do not want to use libtool, you have the power to choose and do not care too much about portability, then you are free to use automake without libtool. I would recommend to use the power of libtool instead.
Actually, I do not even know what _LIBRARY is good for, did not found it in the the manual/Linking section.
I am trying to build an application which depends on Boost. So I downloaded Boost 1_41_0 to my Linux box and followed the instructions found on the Boost site for Unix variants,
http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html.
They basically suggest that I run ./bjam install, which I did. The build completed successfully. However, the library names don't seem to match the Boost naming convention described both in the documentation above, and what is specified in the makefile of the application I am trying to build.
I noticed that there are a bunch of options that I can specify to bjam and I tried to play with those, but no matter what happens I can't seem to get it quite right. My understanding is that the libraries should go into the $BOOST_ROOT/lib directory. This is where the libraries show up, but named:
libboost_thread.a
libboost_thread.so
libboost_thread.so.1.41.0
I'd expect them to be named libboost_thread-gcc41-mt-d-1_41_0 or something similar.
I did try ./bjam --build-type=complete --layout=tagged and I see:
libboost_thread.a
libboost_thread-mt.a
libboost_thread-mt-d.a
libboost_thread-mt-d.so
libboost_thread-mt-d.so.1.41.0
libboost_thread-mt-s.a
libboost_thread-mt-sd.a
libboost_thread-mt.so
libboost_thread-mt.so.1.41.0
libboost_thread.so
libboost_thread.so.1.41.0
So, I am not sure if I should just make stage my -L directory? Is there any documentation which describe this in more detail?
The names was changed in 1.40.0 - see in release notes:
Build System
The default naming of libraries in
Unix-like environment now matches
system conventions, and does not
include various decorations.
They probably forgot to update this part in the build documentation.
There are two variables here. First is "install" vs. "stage" (default). "install" copies both libraries and headers into a directory -- /usr/local by default, and you can then remove source tree. "stage" puts libraries to "stage/lib", and you should add "-L /stage/lib -I " flags.
Second is --layout=versioned and --layout=system. It seems like you have discovered what they do already, and indeed, system is default since 1.40. The getting started guide fails to mention this, and I've added an action item to update it. Ideally, you should talk to the authors of the application to use the system naming of boost libraries. If that's not possible, then building with --layout=versioned is the only option.
From the Boost documentation at http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming, the convention is:
-mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.
-d ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when:
s linking statically to the C++ standard library and compiler runtime support libraries.
g using debug versions of the standard and runtime support libraries.
y using a special debug build of Python.
d building a debug version of your code.
p using the STLPort standard library rather than the default one supplied with your compiler.
n using STLPort's deprecated “native iostreams” feature.
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library in “native iostreams” mode, the tag would be: -sgdpn. If none of the above apply, the ABI tag is ommitted.