i've found myself a few times having to implement logic like so: CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \ CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \ CPPFLAGS=${BUILD_CPPFLAGS} \ LDFLAGS=${BUILD_LDFLAGS} \ CC=$(tc-getBUILD_CC) \ LD=$(tc-getBUILD_LD) \ econf --host=${CBUILD} "$@"
this is to deal with packages that build up not insignificant (let's call them "nificant") binaries which are then used at build time. when cross-compiling, you can't execute those binaries, and things fail. python is a good example. it builds up the local python interpreter (which is all written in C/etc...), and then uses that to parse local python scripts which take care of building everything else. so a while ago we added code so that it'd build two python binaries when cross-compiling: a local ${CBUILD} version which is then used to parse the python build files to compile for ${CHOST}. using host python won't work if it's newer/older/insane/afk. ncurses compiles its local term database by first creating a tic helper and then parsing its local files. we can't use the build system's tic because if the installed ncurses is a different version, we run into fun things like crashes/infinite loops/etc... the latest thing i hit was elfutils where it creates a local binary to generate a database of headers which it then compiles into the target code. so rather than continuing to copy & paste this logic everywhere, i'm going to add it to toolchain-funcs.eclass as "econf_build". any feedback before i do ? -mike
signature.asc
Description: This is a digitally signed message part.