Hi all,
fpc is a pascal-compiler which is able to cross-compile to other architectures. Nothing really special, but it is also able to cross-compile to windows, without any dependencies.
I've created a sub-package of the fpc package to make cross-compiling to windows possible. This package only consist of the run-time-library compiled for windows. But this means that if I commit this package, I add windows binary files (in /usr/lib64/fpc/units/x86_64-win64/)
What are the opinions on this? Rpmlint and strip don't like these files as they are not elf files, but there's no real danger in this?
It would be nice if this sub-package could be added to Fedora, making it possible to compile with fpc for windows directly.
The srpm and the -win64 package can be found here: http://menora.cnoc.nl/extern/fpc/fpc-win64-2.2.4-5.fc11.x86_64.rpm http://menora.cnoc.nl/extern/fpc/fpc-2.2.4-5.fc11.src.rpm
Joost van der Sluis.
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.
On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote:
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.
Those files are not architecture independent. They are somewhat similar to .o files. They contain the run time library for the language, compiled to native windows object files. If you want to compile your own program with them afterwards, they are linked together into a windows executable.
You could argue that they should belong in a -devel package. But since this package is a compiler, we decided not to split it up into a devel package and a non-devel package. As that would be pointless, as one will not work without the other.
Joost
Joost van der Sluis on 10/26/2009 01:42 PM wrote:
Those files are not architecture independent. They are somewhat similar to .o files. They contain the run time library for the language, compiled to native windows object files. If you want to compile your own program with them afterwards, they are linked together into a windows executable.
You could argue that they should belong in a -devel package. But since this package is a compiler, we decided not to split it up into a devel package and a non-devel package. As that would be pointless, as one will not work without the other.
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:
Joost van der Sluis on 10/26/2009 01:42 PM wrote:
Those files are not architecture independent. They are somewhat similar to .o files. They contain the run time library for the language, compiled to native windows object files. If you want to compile your own program with them afterwards, they are linked together into a windows executable.
You could argue that they should belong in a -devel package. But since this package is a compiler, we decided not to split it up into a devel package and a non-devel package. As that would be pointless, as one will not work without the other.
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
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 Mon, Oct 26, 2009 at 07:42:56PM +0100, Joost van der Sluis wrote:
On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote:
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.
Those files are not architecture independent. They are somewhat similar to .o files. They contain the run time library for the language, compiled to native windows object files. If you want to compile your own program with them afterwards, they are linked together into a windows executable.
You could argue that they should belong in a -devel package. But since this package is a compiler, we decided not to split it up into a devel package and a non-devel package. As that would be pointless, as one will not work without the other.
Sorry, I'm late on this one. Yes the files *are* arch independent from the point of view of the host, so they should be noarch. The real problem is that RPM and the rest of the toolchain doesn't understand the cross-compilation situation at all.
Anyway you may find the Fedora MinGW packaging guidelines to be helpful, and it would be useful to make your package compatible with the other ones, even if that deviates from upstream a little bit.
http://fedoraproject.org/wiki/Packaging/MinGW http://fedoraproject.org/wiki/MinGW http://fedoraproject.org/wiki/MinGW/Packaging_issues
We've also packaged some things, such as the OCaml cross-compiler, which sound very similar to the Pascal case you describe.
Rich.
On Tue, 2009-11-03 at 12:56 +0000, Richard W.M. Jones wrote:
On Mon, Oct 26, 2009 at 07:42:56PM +0100, Joost van der Sluis wrote:
On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote:
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.
Those files are not architecture independent. They are somewhat similar to .o files. They contain the run time library for the language, compiled to native windows object files. If you want to compile your own program with them afterwards, they are linked together into a windows executable.
You could argue that they should belong in a -devel package. But since this package is a compiler, we decided not to split it up into a devel package and a non-devel package. As that would be pointless, as one will not work without the other.
Sorry, I'm late on this one. Yes the files *are* arch independent from the point of view of the host, so they should be noarch.
That's true.
Anyway you may find the Fedora MinGW packaging guidelines to be helpful, and it would be useful to make your package compatible with the other ones, even if that deviates from upstream a little bit.
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.
We've also packaged some things, such as the OCaml cross-compiler, which sound very similar to the Pascal case you describe.
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, Nov 05, 2009 at 01:42:55PM +0100, Joost van der Sluis wrote:
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.
This is based on a misunderstanding of the packaging guidelines.
The Fedora MinGW cross-compiler itself does not live in /usr/i686-pc-mingw32, it lives in the usual places like /usr/bin and /usr/lib (it's a native Fedora executable, so obviously this is where it should go).
$ which i686-pc-mingw32-gcc /usr/bin/i686-pc-mingw32-gcc $ ls /usr/lib64/gcc/i686-pc-mingw32/4.3.2/ crtbegin.o include-fixed libssp.a libstdc++.a crtend.o install-tools libssp.la libstdc++.la crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a include libgcov.a libssp_nonshared.la libsupc++.la
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.
You should use a prefix so that autoconf knows how to find your cross-compiler. Read the documentation for AC_CHECK_TOOL.
Rich.
On Thu, 2009-11-05 at 14:06 +0000, Richard W.M. Jones wrote:
On Thu, Nov 05, 2009 at 01:42:55PM +0100, Joost van der Sluis wrote:
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.
This is based on a misunderstanding of the packaging guidelines.
The Fedora MinGW cross-compiler itself does not live in /usr/i686-pc-mingw32, it lives in the usual places like /usr/bin and /usr/lib (it's a native Fedora executable, so obviously this is where it should go). $ which i686-pc-mingw32-gcc /usr/bin/i686-pc-mingw32-gcc $ ls /usr/lib64/gcc/i686-pc-mingw32/4.3.2/ crtbegin.o include-fixed libssp.a libstdc++.a crtend.o install-tools libssp.la libstdc++.la crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a include libgcov.a libssp_nonshared.la libsupc++.la
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.
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.
You should use a prefix so that autoconf knows how to find your cross-compiler. Read the documentation for AC_CHECK_TOOL.
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.
On Thu, Nov 05, 2009 at 04:44:10PM +0100, Joost van der Sluis wrote:
On Thu, 2009-11-05 at 14:06 +0000, Richard W.M. Jones wrote:
On Thu, Nov 05, 2009 at 01:42:55PM +0100, Joost van der Sluis wrote:
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.
This is based on a misunderstanding of the packaging guidelines.
The Fedora MinGW cross-compiler itself does not live in /usr/i686-pc-mingw32, it lives in the usual places like /usr/bin and /usr/lib (it's a native Fedora executable, so obviously this is where it should go). $ which i686-pc-mingw32-gcc /usr/bin/i686-pc-mingw32-gcc $ ls /usr/lib64/gcc/i686-pc-mingw32/4.3.2/ crtbegin.o include-fixed libssp.a libstdc++.a crtend.o install-tools libssp.la libstdc++.la crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a include libgcov.a libssp_nonshared.la libsupc++.la
Yes, I understood that, but the object files in windows-format should be in /usr/i686-pc-fpc/sys-root/fpc/lib, right?
Not necessarily. i686-pc-mingw32-gcc keeps its own internal object files (libgcc.a etc) under /usr/lib{,64} also.
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.
It's nothing to do with what Windows needs. The directory is used because the upstream gcc/mingw toolchain requires it. The sys-root directory is neither used by, nor exported to Windows (in fact, Windows is not involved at any point in the process).
You should use a prefix so that autoconf knows how to find your cross-compiler. Read the documentation for AC_CHECK_TOOL.
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.
Well OCaml has an integrated build system but still uses autotools, so it's not such a surprising thing. Using autotools has other advantages - it's not merely a fancy version of 'make'.
What happens if a project isn't written entirely in Pascal? What happens if you need to detect if the Pascal compiler is installed?
Rich.
-
Joost van der Sluis -
Kevin Kofler -
Michael Cronenworth -
Richard W.M. Jones -
Roland McGrath