Re: Including windows-binary files for cross compiling into package
On Thu, Nov 05, 2009 at 04:44:10PM +0100, Joost van der Sluis wrote:
On Thu, 2009-11-05 at 14:06 +, 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.lalibstdc++.la
crtfastmath.o libgcc.a libssp_nonshared.a libsupc++.a
includelibgcov.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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Including windows-binary files for cross compiling into package
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
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.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
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 ?? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
Joost van der Sluis wrote: Those files are not architecture independent. They are independent of the host architecture, they only depend on the target architecture. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
