If it's true cross support, then that should be a noarch package and the file names it uses should not depend on %{_lib} that way. Arguably it even belongs in %{_sharedir}, since it is fixed binary content across all host machines.

Joost van der Sluis on 10/26/2009 01:42 PM wrote: They should follow mingw's footsteps, shouldn't they? /usr/i686-pc-mingw32/sys-root/mingw/lib equals /usr/x86_64-pc-fpc/sys-root/fpc/lib ??

On Mon, 2009-10-26 at 14:35 -0500, Michael Cronenworth wrote: /usr/x86_64-pc-fpc/sys-root/fpc/lib That's an idea, but then we would be incompatible with upstream. I can try to patch the configuration files of fpc so that it searches for these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the 'standard' location. Also because other packages based in fpc relay on that. And what I've read here is that this path is chosen because mingw needs a root filesystem location. Fpc does not need that, so I think I keep the default locations, if that's ok. Regards, Joost.

On Tue, 2009-11-03 at 12:56 +0000, Richard W.M. Jones wrote: That's true. A little bit? Did you read my other mail on the subject: "That's an idea, but then we would be incompatible with upstream. I can try to patch the configuration files of fpc so that it searches for these binaries in /usr/x86_64-pc-fpc/sys-root/fpc/lib. But I prefer the 'standard' location. Also because other packages based in fpc relay on that. And what I've read here is that this path is chosen because mingw needs a root filesystem location. Fpc does not need that, so I think I keep the default locations, if that's ok." The thing is that fpc does not need a complete build-environment or something like that. It's just the compiler, one executable. Nothing more. And offcourse the compiled object-files, we are discussing the locations of these files only. I think I can patch the compiler and it's configuration files. But I think it's not really doable to patch Lazarus, a freepacal-ide, to use these paths. I can have a look. Another thing, the MinGW packaging guidelines needs the packages to have a 'MinGw' prefix, not suffix. My example used a suffix, like 'fpc-win32'. Do you think I should use 'win32-fpc' instead? Again: this sounds logical when you have a complete build-environment or something like that. But in this case I think 'fpc-win32' is more logical. Joost

On Thu, 2009-11-05 at 14:06 +0000, Richard W.M. Jones wrote: Yes, I understood that, but the object files in windows-format should be in /usr/i686-pc-fpc/sys-root/fpc/lib, right? That's what I meant. If you are actually on windows, MinGW needs a directory-structure with paths like 'lib', 'bin' etc. But fpc doesn't need that. Well, the application should be in 'program files', but I doubt that that's what we want in a Fedora-package. So if this 'sys-root' path mimics a windows-directory structure, that has no advantage whatsoever for the freepascal compiler. Autoconf? With Pascal? What's next, using 'make'? ;) You don't need those tools with Pascal, there's no need for makefiles because of the unit-system. Also, there's no separate compiler-executable for cross compiling to windows. The 'normal' compiler is able to compile for each OS which is supported, as long as the architecture stays the same. (for i386-arm you need a cross-compiler) You can do 'fpc --OS_TARGET=darwin' and you'll get a OS/X executable. Well, that is, if the linker (ld) supports darwin as a target. For windows the fpc-compiler has a build-in linker, so even that is not necessary. The extra package what I want to make consist only of the pre-compiled run time library (rtl and fcl). Joost.