Cross-Compiling Driving Me Crazy

[EvilDragon]

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):

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:

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]

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]

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]

You need to use "-nostdinc" I think, ED ..

didn't know this either. *stored in memory * ty

 

[notaz]

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]

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]

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


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)

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

 

[skeezix]

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]

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.

 

[EvilDragon]

Okay, I'll try moving to DJWillis chain then

 

[EvilDragon]

Bummer, there's no x64 version of DJWillis toolchain yet

 

[torpor]

VirtualBox to the rescue!

 

[ManlyStump]

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!