<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;" bgcolor="#ffffff" text="#2e3436" link="#1b6acb" vlink="#2e3436"><div>Hi Helmut,</div><div><span><pre><pre><br></pre></pre></span></div><div>On Tue, 2021-01-12 at 22:05 +0100, Helmut Grohne wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Hi,</pre><pre><br></pre><pre>I'm coming late to the party and I only understand a fraction of what</pre><pre>you wrote, but the parts I do understand make a lot of sense.</pre></blockquote><div>Better late than never. I'm surprised by the analysis you made, it is quite deep and correct.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>On Mon, Nov 28, 2016 at 05:25:14PM -0800, Ben Longbons wrote:</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On Mon, Nov 28, 2016 at 12:19 AM, Abou Al Montacir</pre><pre><</pre><a href="mailto:abou.almontacir@sfr.fr"><pre>abou.almontacir@sfr.fr</pre></a><pre>> wrote:</pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>For now you can use multi-arch to install fp-compiler</pre></blockquote><pre><br></pre><pre>No, you can't (that was the first thing I thought of):</pre><pre>fp-compiler:i386 depends on binutils:i386 rather than</pre><pre>binutils-i586-linux-gnu, and binutils:i386 isn't multiarch</pre><pre>installable. You'd have to do a full cross chroot, currently.</pre></blockquote><pre><br></pre><pre>I've read the whole discussion and I'm getting the impression that there</pre><pre>are two distinct issues that are conflated inside this bug.</pre></blockquote><div>Maybe even three as you wrote below.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>One one hand, it would be nice to be able to install a foreign</pre><pre>fp-compiler to be able to call an emulated (via qemu) compiler. On the</pre></blockquote><div>This was the idea. But not only, as the foreign RTL should be usable by both a foreign or a native cross compiler.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>other hand it would be nice to be able to install a cross compiler. And</pre></blockquote><div>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.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>then there is a third issue not otherwise mentioned, which is cross</pre><pre>building the compiler itself.</pre></blockquote><div>For me this is not very useful for users, but only for bootstrapping a new target. We can ignore it I think.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>All of them are nice and they interact somewhat with one another, but it</pre><pre>helps to tell these issues apart.</pre></blockquote><div>Maybe a good start is to split this ticket into several ones, each dealing with a unique feature.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>But once the dependency part is fixed, /etc/fpc.cfg can `#INCLUDE</pre><pre>/etc/fpc/$FPCTARGET.cfg` and put `-e/usr/i586-linux-gnu/bin</pre><pre>-Fl/usr/lib/i386-linux-gnu -Fl/lib/i386-linux-gnu -Fl /usr/lib32</pre><pre>-Fl/lib32` in there (each of those .cfg files will have to be manually</pre><pre>written/installed based on the Debian arch (of the fp-compiler</pre><pre>package), the Debian triple (subdir of /usr/lib), the legacy libdir</pre><pre>(/lib32 - actually not sure if this is necessary or not anymore), the</pre><pre>GNU triple (of binutils), and the FPC target (for choice of the</pre><pre>filename)). Incidentally, managing /etc/fpc.cfg through</pre><pre>update-alternatives is a waste since it could be implemented as just</pre><pre>`#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4, an</pre><pre>appropriate upgrade path would need to be written).</pre></blockquote><pre><br></pre><pre>This is the part where I only understand very little. The thing I do</pre><pre>understand is that there is a fpc.cfg that influences how the compiler</pre><pre>behaves and given the "right" fpc.cfg it can mostly act as a cross</pre><pre>compiler.</pre></blockquote><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>As far as I understand though, there is a major piece missing in the</pre><pre>Debian package to make this reality. I've run fpc hello.pas under strace</pre><pre>and I observe that it calls out to ppcx64. If I were to cross compile</pre><pre>for armel, it would likely call into ppcarm, but there is no ppcarm</pre><pre>binary in any :amd64 package. So regardles how we configure it, we'll</pre><pre>need more binaries to make this happen. Please tell if you think this is</pre><pre>wrong.</pre></blockquote><div>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.</div><div>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 ...</div><div><br></div><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>The above is fairly trivial and will get you a multiarch "cross"</pre><pre>compiler, with /etc/ ready for real (non-multiarch fp-compiler (I</pre><pre>*think* the libc6-*-cross packages are only needed because of ld.so</pre><pre>conflicting. but fp-units-* are actually multiarch safe already,</pre><pre>they're just not marked as such - they put all their files in</pre><pre>/usr/lib/fpc/$fpcversion/{units,fpmkinst}/$FPCTARGET/ already)) ones.</pre><pre>Then it's just a SMOC to actually build real cross-compilers binary</pre><pre>packages from the Debian source package.</pre></blockquote><pre><br></pre><pre>I'm not sure yet how you solve the missing binaries, but I'm all for</pre><pre>having cross compilers in the archive.</pre></blockquote><div>The missing binaries can be first emulated by qemu with foreign compilers, and later with a native cross compiler it ever needed.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>The initial point was switching the binutils dependency to</pre><pre>binutils-$triplet. Since binutils 2.30-6, we have binutils-for-host and</pre><pre>that means that we always have a binutils-$triplet:$arch where arch and</pre><pre>triplet match. So if you are ok with ignoring oldstable, you can now</pre><pre>depend on the triplet variant without issues.</pre></blockquote><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>However, I think that doing so is technically wrong. When I straced fpc,</pre><pre>I saw that it calls into ld.bfd. binutils-x86-64-linux-gnu does not</pre><pre>contain ld.bfd, so the dependency is too weak for what fpc uses. In</pre><pre>order for a binutils-$triplet to be a correct dependency, we'd have to</pre><pre>somehow tell fpc to always invoke triplet-prefixed tools such as</pre><pre>x86_64-linux-gnu-ld.bfd.</pre></blockquote><div>We already patch the compiler to call ld.bfd instead of ld, so we can change the name as you wish.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>And given the pointer to fpc.cfg, I looked into it and stumbled into the</pre><pre>-XP option. It is conditional to cross compiling, but given Debian's</pre><pre>packaging of binutils, it is also relevant to foreign installation.</pre><pre>We'll need to teach fpc to always use the -XP option even natively. Once</pre><pre>that is done, we can replace the binutils dependency with</pre><pre>"binutils-$triplet" or if you require backwards compatibility with</pre><pre>stretch "binutils-$triplet | binutils". Once doing these two bits,</pre><pre>foreign installation should become possible.</pre></blockquote><div>I should admit this is new for me, but looks feasible. I can help patching the compiler code to force using -XP as required.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>The next part was fpc as a cross compiler. I think that one of the first</pre><pre>pieces to getting there is ensuring that all the compiler backend</pre><pre>binaries (e.g. ppcx86 or ppcarm) are built for all architectures. This</pre><pre>does not happen today. Any ideas on how to get there?</pre></blockquote><div>You need to compile the source package with special flags to generate a given compiler.</div><div>So this will be as if you build several separate compilers.</div><div><br></div><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>A separate problem (at least for me) is figuring out what the API to</pre><pre>cross building with fpc is. What is a builder expected to do to build</pre><pre>natively or to cross build?</pre><pre><br></pre><pre>How to build sources for some architecture that can be run (aka build</pre><pre>archtecture)?</pre><pre> * fpc answer: Run plain fpc.</pre><pre> * gcc answer: Run plain gcc. In future, this requires a dependency on</pre><pre> gcc-for-build.</pre><pre> * clang answer: Run plain clang.</pre><pre><br></pre><pre>How to build sources for architecture $x with triplet $y?</pre><pre> * fpc answer: ???</pre><pre> * gcc answer: Run $y-gcc. This requires a dependency on</pre><pre> gcc-$y. In future, a dependency on gcc-for-host:$x will also suffice.</pre><pre> * clang answer: Run clang -target $y.</pre><pre><br></pre><pre>Can someone fill in the fpc answer? I kinda suspect that it is "fpc</pre><pre>-P$z" for some $z that can be computed from $x or $y and the o11c gist</pre><pre>has such a mapping.</pre></blockquote><div>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.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>Depending on the answer, the packaging layout may need to change. So</pre><pre>I'll stop here.</pre><pre><br></pre><pre>Hope this helps</pre><pre><br></pre><pre>Helmut</pre></blockquote><div>Yes It helped a lot. thanks a lot and don't hesitate to correct me if I misunderstood some of your comments.</div><div><br></div><div><div class="-x-evo-signature-wrapper" style="white-space: normal;"><span class="-x-evo-signature" id="1423923852.20958.6@karim"><pre><pre>-- <br></pre>Cheers,
Abou Al Montacir</pre></span></div></div></body></html>