Re: default directories in installed library projects
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.
Reply to: