[Pkg-pascal-devel] Bug#845498: Bug#845498: Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Abou Al Montacir]

Hi Helmut,
On Tue, 2021-01-12 at 22:05 +0100, Helmut Grohne wrote:
> Hi,
> I'm coming late to the party and I only understand a fraction of whatyou
> wrote, but the parts I do understand make a lot of sense.
Better late than never. I'm surprised by the analysis you made, it is quite deep
and correct.
> 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.almontacir at 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 thanbinutils-i586-linux-gnu, and
> > binutils:i386 isn't multiarchinstallable. You'd have to do a full cross
> > chroot, currently.
> 
> I've read the whole discussion and I'm getting the impression that thereare
> two distinct issues that are conflated inside this bug.
Maybe even three as you wrote below.
> One one hand, it would be nice to be able to install a foreignfp-compiler to
> be able to call an emulated (via qemu) compiler. On the
This was the idea. But not only, as the foreign  RTL should be usable by both a
foreign or a native cross compiler.

> other hand it would be nice to be able to install a cross compiler. And
This will require more work on the packaging and I should admit that the current
bandwidth of the team is so low that I fear it will be very difficult. Of course
if someone, with enough free time, volunteers I'll be very happy to help. But I
really have very little time for FPC currently.

> then there is a third issue not otherwise mentioned, which is crossbuilding
> the compiler itself.
For me this is not very useful for users, but only for bootstrapping a new
target. We can ignore it I think.
> All of them are nice and they interact somewhat with one another, but ithelps
> to tell these issues apart.
Maybe a good start is to split this ticket into several ones, each dealing with
a unique feature.
> > 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 manuallywritten/installed
> > based on the Debian arch (of the fp-compilerpackage), the Debian triple
> > (subdir of /usr/lib), the legacy libdir(/lib32 - actually not sure if this
> > is necessary or not anymore), theGNU triple (of binutils), and the FPC
> > target (for choice of thefilename)). Incidentally, managing /etc/fpc.cfg
> > throughupdate-alternatives is a waste since it could be implemented as
> > just`#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4,
> > anappropriate upgrade path would need to be written).
> 
> This is the part where I only understand very little. The thing I dounderstand
> is that there is a fpc.cfg that influences how the compilerbehaves and given
> the "right" fpc.cfg it can mostly act as a crosscompiler.
fpc.cfg is a file that gives the path for the RTL (Run Time Library). On Debian
we added a new feature for the compiler to support a #INCLUDE directive. That
one can be used for architecture specific directories. The paths issue is not
only for RTL, but also for the system libraries and the linker configuration. So
a deep analysis is needed. Not sure I have the time to do it for now. But If
done, I can help pointing to the code where we can hack to fix something either
in compiler or in the build system.
> As far as I understand though, there is a major piece missing in theDebian
> package to make this reality. I've run fpc hello.pas under straceand I observe
> that it calls out to ppcx64. If I were to cross compilefor armel, it would
> likely call into ppcarm, but there is no ppcarmbinary in any :amd64 package.
> So regardles how we configure it, we'llneed more binaries to make this happen.
> Please tell if you think this iswrong.
fpc is a pure wrapper that calls an architecture compiler called ppc$TARGET.
ppcx64 is native compiler in x86_64, but allows to compile for all system that
run on this architecture (windows, FreeBSD, ...) as long as related RTL is
available.
If you want to compile for arm, then it will call ppcarm, which is an arm
architecture compiler. It can be a cross compiler, but it can be a shell script
that calls the native foreign ppcarm with quemu. This needs to be further
analyzed for pros and cons. The same ppcarm should also be able to compile for
all arm related OSes like Android ...

However there is still a problem to be solved as we call ppcarm the compiler for
armel and armhf. So there will be a need to hack this in fpc code and send the
patch to upstream.
> > 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.soconflicting. 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
> > binarypackages from the Debian source package.
> 
> I'm not sure yet how you solve the missing binaries, but I'm all forhaving
> cross compilers in the archive.
The missing binaries can be first emulated by qemu with foreign compilers, and
later with a native cross compiler it ever needed.
> The initial point was switching the binutils dependency tobinutils-$triplet.
> Since binutils 2.30-6, we have binutils-for-host andthat means that we always
> have a binutils-$triplet:$arch where arch andtriplet match. So if you are ok
> with ignoring oldstable, you can nowdepend on the triplet variant without
> issues.
I don't think old-stable is important anymore. However the real issue, as you
say later, is that we can not use ls, but ld.bfd.
> 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 notcontain ld.bfd,
> so the dependency is too weak for what fpc uses. Inorder for a binutils-
> $triplet to be a correct dependency, we'd have tosomehow tell fpc to always
> invoke triplet-prefixed tools such asx86_64-linux-gnu-ld.bfd.
We already patch the compiler to call ld.bfd instead of ld, so we can change the
name as you wish.
> 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'spackaging of
> binutils, it is also relevant to foreign installation.We'll need to teach fpc
> to always use the -XP option even natively. Oncethat is done, we can replace
> the binutils dependency with"binutils-$triplet" or if you require backwards
> compatibility withstretch "binutils-$triplet | binutils". Once doing these two
> bits,foreign installation should become possible.
I should admit this is new for me, but looks feasible. I can help patching the
compiler code to force using -XP as required.
> The next part was fpc as a cross compiler. I think that one of the firstpieces
> to getting there is ensuring that all the compiler backendbinaries (e.g.
> ppcx86 or ppcarm) are built for all architectures. Thisdoes not happen today.
> Any ideas on how to get there?
You need to compile the source package with special flags to generate a given
compiler.
So this will be as if you build several separate compilers.

I would advise to make the cross compilers as separate source package that
relies on FPC source. Otherwise it will be too complicated to package any new
version. But it is feasible.
> A separate problem (at least for me) is figuring out what the API tocross
> building with fpc is. What is a builder expected to do to buildnatively or to
> cross build?
> How to build sources for some architecture that can be run (aka
> buildarchtecture)? * 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 gisthas such a
> mapping.
The answer is ver easy; fpc -P$z where $z is the suffix of the arch
(cross)compiler. The suffixes are defined by upstream, but the rules file
manages to detect them for each dpkg arch using a mapping table. We cal also add
a helper program that returns fpc arch from dpkg arch.
> Depending on the answer, the packaging layout may need to change. SoI'll stop
> here.
> Hope this helps
> Helmut
Yes It helped a lot. thanks a lot and don't hesitate to correct me if I
misunderstood some of your comments.

-- 
Cheers,
Abou Al Montacir


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20210121/38704681/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20210121/38704681/attachment-0001.sig>