Hi,
I'm coming late to the party and I only understand a fraction of what
you wrote, but the parts I do understand make a lot of sense.
On Mon, Nov 28, 2016 at 05:25:14PM -0800, Ben Longbons wrote:
> On Mon, Nov 28, 2016 at 12:19 AM, Abou Al Montacir
> <abou.almonta...@sfr.fr> wrote:
> > For now you can use multi-arch to install fp-compiler
>
> No, you can't (that was the first thing I thought of):
> fp-compiler:i386 depends on binutils:i386 rather than
> binutils-i586-linux-gnu, and binutils:i386 isn't multiarch
> installable. You'd have to do a full cross chroot, currently.
I've read the whole discussion and I'm getting the impression that there
are two distinct issues that are conflated inside this bug.
One one hand, it would be nice to be able to install a foreign
fp-compiler to be able to call an emulated (via qemu) compiler. On the
other hand it would be nice to be able to install a cross compiler. And
then there is a third issue not otherwise mentioned, which is cross
building the compiler itself.
All of them are nice and they interact somewhat with one another, but it
helps to tell these issues apart.
> But once the dependency part is fixed, /etc/fpc.cfg can `#INCLUDE
> /etc/fpc/$FPCTARGET.cfg` and put `-e/usr/i586-linux-gnu/bin
> -Fl/usr/lib/i386-linux-gnu -Fl/lib/i386-linux-gnu -Fl /usr/lib32
> -Fl/lib32` in there (each of those .cfg files will have to be manually
> written/installed based on the Debian arch (of the fp-compiler
> package), the Debian triple (subdir of /usr/lib), the legacy libdir
> (/lib32 - actually not sure if this is necessary or not anymore), the
> GNU triple (of binutils), and the FPC target (for choice of the
> filename)). Incidentally, managing /etc/fpc.cfg through
> update-alternatives is a waste since it could be implemented as just
> `#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4, an
> appropriate upgrade path would need to be written).
This is the part where I only understand very little. The thing I do
understand is that there is a fpc.cfg that influences how the compiler
behaves and given the "right" fpc.cfg it can mostly act as a cross
compiler.
As far as I understand though, there is a major piece missing in the
Debian package to make this reality. I've run fpc hello.pas under strace
and I observe that it calls out to ppcx64. If I were to cross compile
for armel, it would likely call into ppcarm, but there is no ppcarm
binary in any :amd64 package. So regardles how we configure it, we'll
need more binaries to make this happen. Please tell if you think this is
wrong.
> The above is fairly trivial and will get you a multiarch "cross"
> compiler, with /etc/ ready for real (non-multiarch fp-compiler (I
> *think* the libc6-*-cross packages are only needed because of ld.so
> conflicting. but fp-units-* are actually multiarch safe already,
> they're just not marked as such - they put all their files in
> /usr/lib/fpc/$fpcversion/{units,fpmkinst}/$FPCTARGET/ already)) ones.
> Then it's just a SMOC to actually build real cross-compilers binary
> packages from the Debian source package.
I'm not sure yet how you solve the missing binaries, but I'm all for
having cross compilers in the archive.
The initial point was switching the binutils dependency to
binutils-$triplet. Since binutils 2.30-6, we have binutils-for-host and
that means that we always have a binutils-$triplet:$arch where arch and
triplet match. So if you are ok with ignoring oldstable, you can now
depend on the triplet variant without issues.
However, I think that doing so is technically wrong. When I straced fpc,
I saw that it calls into ld.bfd. binutils-x86-64-linux-gnu does not
contain ld.bfd, so the dependency is too weak for what fpc uses. In
order for a binutils-$triplet to be a correct dependency, we'd have to
somehow tell fpc to always invoke triplet-prefixed tools such as
x86_64-linux-gnu-ld.bfd.
And given the pointer to fpc.cfg, I looked into it and stumbled into the
-XP option. It is conditional to cross compiling, but given Debian's
packaging of binutils, it is also relevant to foreign installation.
We'll need to teach fpc to always use the -XP option even natively. Once
that is done, we can replace the binutils dependency with
"binutils-$triplet" or if you require backwards compatibility with
stretch "binutils-$triplet | binutils". Once doing these two bits,
foreign installation should become possible.
The next part was fpc as a cross compiler. I think that one of the first
pieces to getting there is ensuring that all the compiler backend
binaries (e.g. ppcx86 or ppcarm) are built for all architectures. This
does not happen today. Any ideas on how to get there?
A separate problem (at least for me) is figuring out what the API to
cross building with fpc is. What is a builder expected to do to build
natively or to cross build?
How to build sources for some architecture that can be run (aka build
archtecture)?
* fpc answer: Run plain fpc.
* gcc answer: Run plain gcc. In future, this requires a dependency on
gcc-for-build.
* clang answer: Run plain clang.
How to build sources for architecture $x with triplet $y?
* fpc answer: ???
* gcc answer: Run $y-gcc. This requires a dependency on
gcc-$y. In future, a dependency on gcc-for-host:$x will also suffice.
* clang answer: Run clang -target $y.
Can someone fill in the fpc answer? I kinda suspect that it is "fpc
-P$z" for some $z that can be computed from $x or $y and the o11c gist
has such a mapping.
Depending on the answer, the packaging layout may need to change. So
I'll stop here.
Hope this helps
Helmut
