I’ve been able to cross compile Panda3D using a toolchain, but when I try to run it on the target, I’ve got issues with the installation path. On the host, I had to install in a sysrooted environment. On the target, the Config.prc is not found (I corrected that by defining the $PRC_DIR env-var), but now I’m stuck with the “pandagl” module that cannot be loaded (but it exists).
Is there a way to tell Panda3D where to find libpandagl.so ?
Oh. In that case, I don’t know. The issue was only for a short while on CVS, as far as I remember, and it had to do with the -i flag not being passed to the “flex” utility, which means that it did not generate a case-insensitive lexer to lex the .egg files.
I’ve tweaked the build system, and it’s alright now. Strangely, the
#define LFLAGS -i
in the egg source directory (Source.pp) is passed to the g++ linker (and crash the link process, cause gcc doesn’t understand it), not to flex (??) so I commented out this line… Then, I modified the flex binary to
#defer FLEX flex -i
in my Config.pp, and it works. It’s a ugly hack, but I don’t know pass flags to flex with the ppremake system.
in your Sources.pp for the ppremake system with the code from CVS since about 3 weeks.
If you really want to work with the Panda3D 1.8.1 release, you’d need to use an older version of the GCC compiler (4.2 works, 4.7.2 does not accept the invalid -i option anymore).
Right, the problem was that LFLAGS was actually used for two things: as linker flags and as flex flags. This mistake wasn’t spotted because earlier versions of gcc simply ignored the -i flag. To fix this ambiguity, drwr recently renamed the flex flags variable to FLEXFLAGS on CVS.