Hi,
On Mon, Oct 12, 2009 at 06:14:12PM +0200, Hector Oron wrote:
>> Utilizing Multiarch
>> Multiarch already goes most of the way by specifying new paths where
>> libraries are to be found; while the MultiarchSpec lists library -dev
>> packages as unresolved, the transition plan is already pretty specific
>> on making binutils and gcc look into multiarch directories, which is
>> only needed for -dev packages.
> % Note that binutils package has not been tough how to look in the
> multiarch paths, just gcc (for the suite of compilers).
Yep. TBH, I'd rather have gcc tell ld to ignore its own search path and
specify the path explicitly on the command line, so that ld's path is
only relevant for people calling it directly. This still means that ld's
notion of the library path must be fixed, but I don't like having this
information split between multiple packages.
The MultiarchSpec already lists ld as one of the places that needs to be
adapted, so no action required for emdebian here.
>> Some extra work will be required to handle package-config .pc files
>> (by teaching package-config about the new directories) and
>> architecture-dependent headers (which are installed below /usr/lib by
>> several packages). These can be dealt with by patching individual
>> packages.
> % Arch dependent headers are under /usr/include (typo?), we should
> propose to add a multiarch like path for headers
> (/usr/include/$triplet).
That is already mentioned in the MultiarchSpec, although under
"unresolved issues".
I use /usr/include/$triplet already, and gcc uses it by default, so the
implementation is already further along than the spec.
Using built-in specs.
Target: x86_64-linux-gnu
[...]
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/include
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
Most packages that install arch-dependent headers really do install them
below /usr/lib, for example "/usr/lib/glib-2.0/include/glibconfig.h".
> dpkg-cross also handles .pc files. (Need to design a plan for
> dpkg-cross -> dpkg merge, Neil?)
Yes and no. dpkg-cross needs to adapt the .pc files because the paths
change. With multiarch, this is no longer the case, so simply installing
them into an arch-specific path (/usr/lib/pkgconfig/$triplet) should
suffice -- we just need to extend the spec for this.
>> we would like to take up the opportunity to introduce a host/target
>> distinction in build dependencies in Debian at the same time, even if
>> Debian itself would not use that information. This would be cheap to
>> do at this stage, as the dependency handling code needs to be adapted
>> anyway to handle architecture-qualified dependencies; we propose that
>> in build dependencies, the special qualifiers ":build" and ":host" can
>> be appended to package names. When not cross-compiling, these can and
>> should be treated as if they were not present. The ":any" qualifier
>> would have the same meaning as for regular dependencies, i.e. it would
>> allow the dependency to be met by any package with an architecture
>> that can be executed on the host, regardless of whether that is the
>> same architecture as the current DEB_BUILD_ARCH.
> % Why ":build" and ":host"? I think you need to define what do you
> understand by ":build" and ":host" semantics, why not ":target"?
So these are consistent with the naming of $DEB_BUILD_ARCH and
$DEB_HOST_ARCH.
":build" means "exactly the build architecture" and ":host" means
"exactly the host architecture".
Basically, the resolution would work like this:
unqualified :build :host :any
undeclared -> build -> build error error
same -> host -> build -> host error
foreign -> build -> build error -> build
allowed -> build -> build error -> any
Hmm. Seems we don't actually need ":host", except if I made a mistake in
the table or if we want the extra error checking.
> Would
> not make more sense to use another Build-Dependencies(-Cross) field
> for the target (as in GNU definition) case, having a knob to change
> dependencies per architecture with "[arch]" tags (is this really
> needed)?
Using "libfoo-dev:build [i386], libbar-dev [amd64]" would be perfectly
fine.
> Also how do you use this features in the CLI?
That would need to be implemented in apt, e.g. in the form of
$ apt-get -a armel build-dep foo
dpkg doesn't really care about build dependencies other than checking
them in dpkg-checkbuilddeps.
Simon
Attachment:
signature.asc
Description: Digital signature