Cross-Compiling Driving Me Crazy


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,717
Age
43
Location
Ingolstadt
Okay, I'm trying to cross-compile some things, but they're trying me crazy...
Using CodeSourcery, built the toolchain according to cpasjuste's manual.

One thing is driving me crazy:

cc1: warning: include location "/usr/include/SDL" is unsafe for cross-compilation

Well, the system is right, /usr/include/SDL IS unsafe for cross-compilation.
However, when running the ./configure-script, I always use --includedir=/home/michi/pandora-dev/arm-2009q3/usr/include --libdir=/home/michi/pandora-dev/arm-2009q3/usr/lib

When I take a look in the Makefile, the directories also seem to be correct.
For example, trying to compile penguin-command (part of the makefile):

Code:
CFLAGS = -g -O2 -I/home/michi/pandora-dev/arm-2009q3/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Wall -DJOYSTICK -DDATADIR="\"${datarootdir}/penguin-command\""
LDFLAGS = -Wl,-rpath -Wl,/home/michi/pandora-dev/arm-2009q3/usr/lib -L/home/michi/pandora-dev/arm-2009q3/usr/lib -L/home/michi/pandora-dev/arm-2009q3/arm-none-linux-gnueabi/libc/lib -L/home/michi/pandora-dev/arm-2009q3/arm-none-linux-gnueabi/libc/usr/lib -L/home/michi/pandora-dev/arm-2009q3/usr/lib -s
SDL_CFLAGS = -I/home/michi/pandora-dev/arm-2009q3/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
SDL_CONFIG = /home/michi/pandora-dev/arm-2009q3/usr/bin/sdl-config
SDL_LIBS = -L/home/michi/pandora-dev/arm-2009q3/usr/lib -lSDL
LIBS = -L/home/michi/pandora-dev/arm-2009q3/usr/lib -lSDL

So, yeah, paths seem fine.

However, when I run make, it runs, for exmample the following command-line:

Code:
arm-none-linux-gnueabi-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"penguin-command\" -DVERSION=\"1.6.11\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MATH_H=1 -DHAVE_LIBM=1 -I. -I.     -g -O2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Wall -DJOYSTICK -DDATADIR="\"/usr/local/share/penguin-command\"" -MT joystick.o -MD -MP -MF ".deps/joystick.Tpo" -c -o joystick.o joystick.c;

So... where the heck is that -I/usr/include/SDL coming from? It's NOWHERE in the Makefile.
It's the same with ClawsMail (also using automake)...

How the heck can I tell the system to NOT use the wrong include-dirs?

Thanks for any help.
 

WizardStan

Mega GP Mania
Joined
May 24, 2008
Messages
16,733
What's the output of the command
/home/michi/pandora-dev/arm-2009q3/usr/bin/sdl-config --cflags
?
sdl-config is a program installed with SDL that's supposed to know where it's libraries and includes are. If I'm right, the cross compiler you have installed didn't set it up properly, and it is returning "-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT" or something like that.
Open the makefile and change the line
SDL_CONFIG = /home/michi/pandora-dev/arm-2009q3/usr/bin/sdl-config
to be
SDL_CONFIG = /home/michi/pandora-dev/arm-2009q3/usr/bin/sdl-config --prefix=/home/michi/pandora-dev/arm-2009q3

That should set it straight.
 

torpor

hack hack hack, the little machines fight back
Joined
Oct 21, 2005
Messages
2,475
Location
vienna, austria
Website
w1xer.at
You need to use "-nostdinc" I think, ED ..

http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

EDIT: If WizardStan is right, don't forget that you can manually edit the .pc file for SDL, and point it to the right place ..
 

crow_riot

Well-Known Member
Joined
Sep 21, 2009
Messages
1,763
Location
.at
torpor said:
You need to use "-nostdinc" I think, ED ..

didn't know this either. *stored in memory ;)* ty
 
Last edited by a moderator:

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
Well that ./configure system is called autohell for a reason, it tends to stick /usr/ paths no matter what for some programs. This time it may be coming from sdl-config though, like said.
 

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,717
Age
43
Location
Ingolstadt
Since I checked the Makefiles and couldn't find and /usr/lib-etc. things left (yeah, automake PUT them in there, I fixed them manually!) I also guess it's in sdl-config.
I'll try tonight.

However, claws-mail was looking for /usr/include/glib-2.0 and stuff like that... that's no SDL... could that also be because of the config?
 

sebt3

homebrew player (P. & C.)
Joined
Sep 9, 2008
Messages
4,846
Age
40
Location
France
Website
sebt3.openpandora.org
notaz said:
Well that ./configure system is called autohell for a reason, it tends to stick /usr/ paths no matter what for some programs. This time it may be coming from sdl-config though, like said.
While not easy to deal with, my mains problems with the auto* build system are :
- most developper don't know at all how to use it :( I've seen myself sending pach for configure.ac, Makefile.in ... files many times already...
- libtool
- libtool
- and libtool
:D

Then there are some quirk with it also : AC_TRY_RUN autoconf macro isn't cross-compiling friendly. But edit configure.ac and "autoconf" and be done with that :) (ok you'll need autoreconf sometimes)

I'm always able to get around trouble with auto-tools and most of the time it just works :)

This is not the case with most others build-system. The only 2 cross-plateform friendly build system : qmake and cmake. Both are pkg-config based like autotools but don't use libtool.
qmake is used only for qt apps. So it's scope rapidly fade :(
cmake use a toolchain definition file. I've yet to find a way to use only one of these. If I try to, the configure command end ups looking like cmake -DVERY_LONG_VARIABLE_TO_SET=val -DOTHER_VERY_LONG_VARIABLE_TO_SET=val -DYET_OTHER_VERY_LONG_VARIABLE_TO_SET=val -D_AGAIN_A_VERY_LONG_VARIABLE_TO_SET=val .... etc which don't help the building experience :(

And then, you have the "custom". Those developpers _realy_ _don't_ know what they are f**king doing ! Most of the time, I have to rewrite part of the build system. If you're lucky, you just have to unset/fix some variables (CC, CFLAGS etc) set in their makefiles. But if you're not lucky, you end-up writing a new Makefiles (geez try to cross-compile libnss. If you manage that using the official build system, I want to know how the f*** you manage this holy glory)


EvilDragon said:
Okay, I'm trying to cross-compile some things, but they're trying me crazy...
Using CodeSourcery, built the toolchain according to cpasjuste's manual.
Hi ED,
Most of your problem is because you're using a deprecated toolchain. Read what it's autor have to say about it (2times...)
DJWillis' toolchain set PKG_CONFIG_SYSROOT_DIR which will make pkg-config happy
 
Last edited by a moderator:

skeezix

Internal Development
Joined
Mar 11, 2003
Messages
8,064
Website
www.codejedi.com
Actualy, /usr/include generally _is_ safe; ideally you have a whole other tree of headers somewhere :)

ITs the lib path that is totally unsafe ... but also something that ld is smart enough to ignore; CSL/gcc will complain that the default include and lib paths aren't safe for cross-compilation, but in practice its just an annoying warning you can ignore.

-nostdinc can be a pita but thats more or less how you go about it; the configure scripts are adding additional include paths usually, not replacing the default.

jeff
 

Hitnrun

Member
Joined
Mar 1, 2008
Messages
427
Yes as sebt3 said, the DJwillis toolchain is already configured with the correct (hardcoded?) paths, I was getting these messages too with this other toolchain, on the DJwillis's one just

# ./configure --host=xxx

and everything works.
 

ManlyStump

Member
Joined
Aug 29, 2010
Messages
172
Man, I was feeling stupid for not being able to set up CodeBlocks to work with cross-compiling for Pandora, but I'm getting the exact same error. If Evil Dragon's having the same problem as me, I feel much better about it! :D
 
Top