No, there is only one fpc.cfg on my computer and that's the one in /etc/

I tried ppcppc, but it turned it to be a PowerPC binary and it has endian issues <http://www.freepascal.org/mantis/view.php?id=9165>.

so what changed? Maybe it's better to take this to the mailing list, because this doesn't sound like a bug to me but a configuration problem.

I am doing that now, but I bet it's a bug. Even if not, why is the build system so obscure "some configuration file you have somewhere" that this can happen ?

I am not at all saying that FPC should follow GNU conventions, no, but at least the rules are clear there. You configure for target, host and build and then the Makefile takes cares of the rest. If a configuration is not supported or if there is a problem, you get a clear error message.

Anyway, keep up the excellent work,

Regards,

Adriaan van Os

Adriaan van Os wrote

> Maybe you have a ~/.fpc.cfg, or an fpc.cfg in the current directory? No, there is only one fpc.cfg on my computer and that's the one in / etc/

Note the spelling of the first file: .fpc.cfg. Anyway, it doesn't matter, see below.

That's by design (I now see I read your 9165 bug report wrongly). When doing a cross make all, you create both a cross compiler (ppcrossXXX) and a native compiler for the selected target platform (which can be used for bootstrapping on the target platform).

and it has endian issues <http://www.freepascal.org/mantis/view.php? id=9165>.

I meant before that. Or was that the first time ever you tried to compile a PowerPC binary on an Intel Mac?

Using ppu files with compilers compiled for a different endianess than the compiler which generated those ppu files is simply something which is not supported at this time, because no one does that anymore nowadays (although Daniel is now trying to fix that -- and yes, we should have given an error message instead of failing due to reading invalid data from ppu files, but as I said, nobody even tried that for a very long time). It is not needed either for cross compiling, because all ppu files are generated using the cross compiler (and the created native compiler is only intended for bootstrapping).

I'm sorry, but I'm not sure what is obscure here:
a) Under *nix, FPC, like pretty much every other *nix app out there, supports three different default locations for configuration files, which are sought in the order current directory, home directory, global config directory (/etc on e.g. Mac OS X and Linux, /local/etc under *BSD, ...)
b) when cross compiling, you can configure a prefix which has to be prepended to the names of the binutils. This is done using the -XP parameter.

You indeed cannot do point b) with gcc afaik, because I believe that there the prefixes are hardcoded in the binary (probably specifiable as parameter to configure). It's debatable whether this is an advantage.

As I asked, please try to use "-va" to see which config files are loaded by the compiler and which options it encounters and parses.

And just like you now have a problem with fpc, other people also sometimes have trouble getting cross gcc to build/install properly. The number of howto's on how to build, install and use a cross-gcc is quite big.

If a configuration is not supported or if there is a problem, you get a clear error message.

Not always.

Jonas

Op Tue, 3 Jul 2007, schreef Adriaan van Os:

I am not at all saying that FPC should follow GNU conventions, no, but at least the rules are clear there. You configure for target, host and build and then the Makefile takes cares of the rest. If a configuration is not supported or if there is a problem, you get a clear error message.

The rules themselves are pretty clear: You have the PowerPC compiler on your system. This PowerPC compiler is capable of generating programs for MacOS classic, MacOS X, Linux and MorphOS.

You run in on OS X, but that is not really important here, except that by default it is configured to generate programs for OS X, and if you compile for this default it calls "as" and "ld". If you do not use the default, you probably need a different assembler and linker, and can use -XP option to specify how they are called.

To help you the installation script puts "-XP$fpctarget-" in your config file, so that if you compile for Linux the compiler will search for powerpc-linux-as and powerpc-linux-ld.

If things don't work out as expected, this is regrettable, but troubleshooting this is at least as least not harder than troubleshooting an unexpected Autoconf failure.

Daniël

Adriaan van Os wrote

build and then the Makefile takes cares of the rest. If a configuration is not supported or if there is a problem, you get a clear error message.

You *must* be joking, right ? Usually it involves digging through a messy config.log, where you sometimes can't really find the reason (just one of those mysterious test compiles failed) and then have to decrypt an enormously complex configure script that will give you nightmares for years.

Micha

I second that. Autoconf is the worse building method I have ever seen.

And I've already seen some pretty scary things, like the SymbianOS build method with hundreds of perl scripts that call batch files, which create makefiles, which call more perl scripts to create more batch scripts, and so on recursively.