On 5/20/07, Sven Luther <[EMAIL PROTECTED]> wrote:
On Sat, May 19, 2007 at 04:46:04PM +0900, Charles Plessy wrote:
> Out of the 140 packages using ./configure, 30 used ppc64, but only one > faild to build for this reason. These .configure thingies, are they using the gnu autoconf stuff, and if so which version. Or some hand-made ./configure script ? I guess those packages will also probably break if building cross-compiled, so they are also buggy.
They certainly break under the given conditions: 1. you actually ARE cross compiling 2. you didn't tell the package that (via make arguments, etc.) That's the messed up situation you're in. Don't do that. Many more packages may build incorrectly, probably spewing a few warnings about data type sizes. If you can't find a normal 32-bit PowerPC box, I suggest using Qemu or PearPC on a fast x86 or x86-64 box. That way you wouldn't be cross-compiling. In the long term, it would be great to cross-compile all packages on the "wrong" architecture. This would flush out a lot of bugs and make porting Debian much easier. (so i386 on ppc64, x86-64 on s390, arm on ia64, etc.) For a popular arch, build both native and not so that you can check that the results are bit-for-bit identical. You can't just start doing this though. When you are cross-compiling (as you are for ppc32), you need to adjust each package to supply the required command line options and environment variables to the build system supplied by the upstream developer. In some of the more crufty cases you may need patches. It's package-specific. For example: you might need to choose between /lib or /lib64, you might need to specify endianness, you might need to specify gcc flags like -m32 or -m64, etc. When I design a build system I want this stuff passed on the make command line, but other people use environment variables or configure scripts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
