arm-linux-gnueabi-ld and fpc ppcrossarm still links to linux-i386 - linux

I was able to build a freepascal crosscompiler for arm, but now when i want to build a a simple graphical app in lazarus or rebuild LCL the compilation works until is called arm-linux-gnueabi-ld which one still looking for all graphics librarys in /usr/lib/gcc/i586-linux-gnu/4.9/ instead /usr/lib/gcc/arm-linux-gnueabi/4.9. so how i can fix it?
/usr/bin/arm-linux-gnueabi-ld: skipping incompatible /usr/lib/gcc/i586-linux-gnu/4.9/crtbegin.o when searching for /usr/lib/gcc/i586-linux-gnu/4.9/crtbegin.o

Put the relevant -FD or -Fl lines in your fpc.cfg under #ifdef i386
So e.g.
#ifdef cpui386
-Fl/lib
-Fl/usr/lib
-Fl/usr/lib/i586-linux-gnu/4.9
#endif
and add an appropriate entry for ARM
See here for a list of architecture specific defines. The Buildfaq has some more detailed information.

Related

How to check the compiler version in Qt .pro file?

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.

Differences between compiled dalvik binaries

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

jiffies.h unknown

I'm using a Linux 2.6.36 on a embedded system. I try to program something with semaphores. For this I need a function from the jiffies.h library. So good so far. When I include the Lib
either this way
#include <jiffies.h>
or this way
#include <linux/jiffies.h>
works.
But the strange thing is if I go to open declaration (eclipse comand) it opens an new editor window with the library. Does anyone have a clue what to do?
You are probably not building your module correctly. A kernel module Makefile is extremely simple, and should look something like this, in its entirety:
obj-m := mymodule.o
mymodule.ko: mymodule.c mymodule.h
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
The kernel build system will do the rest. For more details, see the chapter on building modules at http://lwn.net/Kernel/LDD3/
Editing:
Now it appears maybe you aren't trying to write a kernel module after all. In that case, you don't want any include files that are part of the kernel source. jiffies.h is not a userland include; it is a part of the kernel, used in writing parts of the kernel. For userland semaphores, try POSIX semaphores. Start with man sem_overview, and/or Google "POSIX semaphore".
One mystery is solved: Eclipse store all file names in a project in a kind of list and when I click on show declaration it search in the list for that name and display the file. So it doesn't say anything about the compiler and the linker if this work. If that is not true please correct me.

Compiling mDNSResponder for Linux?

I've been trying to compile the open source Bonjour framework developed by Apple for Linux. The problem I have is that when I run make with the option os=linux I get the following compile error:
struct sockaddr has no member named 'sa_len'
I've checked the struct sockddr and it indeed has no member named sa_len... So I'm confused as to why the framework is thinking that it should do!
Could anyone please give me some advice as to how I should be compiling mDNSResponder for Linux? Many thanks.
Looking in mDNSUNP.h one can see that if sa_len does not exist (such as on Linux), a macro NOT_HAVE_SA_LEN should be defined. If it's not defined in your case, try adding -DNOT_HAVE_SA_LEN to your compilation flags.
The Linux implementation of sockaddr doesn't have sa_len as a member, but the FreeBSD version does. Apple's implementation is based off of the FreeBSD version (parts of OS X pull from FreeBSD and NetBSD), hence why you're receiving that error. You can use an #ifdef to workaround it or add the compilation flag, as previously suggested.

VC++ 2010 wants to link boost libararies i didn't even specify

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.

Resources