Björn Persson writes: > Nicolas Boulenguez wrote: >> This message answers >> https://lists.debian.org/debian-ada/2013/09/msg00005.html >> >>> users have to use setarch instead of passing an option such as -m32 >> >> Gnat will not be able to cross-compile before long. > > Are you saying that all multiarch and cross-compilation functionality > will be removed from Gnat? In Debian or in the upstream GCC sources? > How will Gnat be bootstrapped on new architectures then?
I'd like to rephrase what Nicolas said. GNAT can cross-compile and that has been the case for years. However, upstream GNAT will not support multiarch anytime soon. For the C language, the /usr/bin/gcc compiler driver supports multiarch; this means that compile-time options like -m32, -march etc. cause it to select one of several installed "cc1" compilers and "ld" linkers, each emitting object code for a different target, and also to select the appropriate default include directories and libraries. Unfortunately, the same does not apply to /usr/bin/gnatmake for the Ada language. If you want to compile Ada for, say, both 32- and 64-bit targets, you need two independent installations of the compiler, i.e. two different gnatmakes, two different gccs, etc., none of which actually supports multiarch. For now, I've only been able to provide native compilers. People wanting to cross-compile Ada from Debian must build their own GNAT and install it in /usr/local. This locally-built cross-compiler can build a native GNAT compiler for a foreign architecture; this is how GNAT was ported to all the hardware architectures that Debian supports. >> Why not hardcode the hardware platform into directories.gpr? Could >> you give an example where gnat needs to receive a target architecture >> at compile time? > > If each binary Gnat package can only be used to compile for a single > architecture, there can never be more than one Gnat present at a time, > and each Gnat package comes with its own version of the directories > project, then a constant Hardware_Platform should work. You'll need to > prevent a situation where a 32-bit Gnat and a 64-bit GPRbuild are > installed, and GPRbuild doesn't find the directories project because > Gnat installs it in a 32-bit directory but GPRbuild looks for it in a > 64-bit directory. Yes, I think this is appropriate. > If that is the case, then it seems rather pointless to install -dev > packages for other architectures than the compiler's target > architecture, so it shouldn't matter much if they aren't multiarch- > compatible. Correct. I can build 32-bit binaries on my admd64 machine but only in a 32-bit chroot with a 32-bit native GNAT installed in it. > Fedora's GtkAda-devel package stores both package specifications and > bodies in /usr/include/gtkada. The 32- and 64-bit versions of the > package can both be installed at the same time. There is no conflict > because all of the source files are identical in both packages. They > just share ownership of the files. If any of the files were different, > then RPM would see a conflict and refuse to install both packages. > > I don't know about the other three but for a binding to GTK+ there is > apparently no need for anything architecture-dependent. Yes, the *.ad[bs] files are identical in GtkAda but the *.ali files must be different, since they refer to different versions of system.ads. Therefore, the .ali files must be in an architecture-dependent directory. But I think Nicolas was referring to the general case where Ada source files can be architecture-dependent, similarly to system.ads. For example, they might contain different representation clauses. The fact that GtkAda sources are all architecture-independent is a particular case; no general rule can be inferred from them. Personally I'm tempted to drop this issue altogether, since multiarch development packages require a multiarch compiler, which is not happening any time soon anyway. We have, in the past, attempted to follow the Debian standard for multiarch development packages (they seem to work similarly to multiarch RPMs: they can share identical files but files that are architecture-dependent must have different absolute paths). But that effort was mostly wasted :/ -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
