Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   Bug#180128: state of integration of dpkg-cross into dpkg (http://www.linux-archive.org/debian-dpkg/686226-bug-180128-state-integration-dpkg-cross-into-dpkg.html)

Neil Williams 07-22-2012 04:05 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Wed, 18 Jul 2012 19:11:38 +0200
Guillem Jover <guillem@debian.org> wrote:

> > The bulk of the patch is now out of date but rather than spend time
> > updating the patch, work is ongoing to merge the existing dpkg-cross
> > package (which includes all the cache values and architecture support)
> > into dpkg itself, sometime after Lenny.
> >
> > Far better, in my view, to remove the 'patch' tag from this report, keep
> > it open as wishlist and I'll merge it with the eventual bug report that
> > implements an updated patch (arranged with Guillem) that fully merges
> > dpkg-cross into dpkg and then remove dpkg-cross (and apt-cross) from
> > unstable.
>
> So, was checking this (and also the dpkg roadmap) and was wondering what
> else is still missing to be merged from dpkg-cross? If the only problem
> is the listed below, then it'd seem this bug has been resolved and it
> can be closed.

One unresolved issue is the cache values and architecture support:
where to put the cross- config settings currently implemented
in /etc/dpkg-cross/cross* which pass the architecture-specific values
to autotools projects. CC'ing debian-embedded for more input on
that.

e.g. /usr/share/perl5/Dpkg/Shlibs.pm contains numerous references to
dpkg-cross-style paths which pick up these files as well as allow
dpkg-cross'd libraries to be usable whilst MultiArch is still being
rolled out.

This parallel support needs to be retained until some "critical mass"
of libraries and -dev packages are completely MultiArch compliant. At
that point (and not before) dpkg-cross would change into a transitional
package which is merely a configuration shell with no command-line
interface (and no perl module) but which just provides the
existing /etc/dpkg-cross/cross* data. At that point, xapt would have to
be removed from Debian.

My proposal would be that this transition is marked as dpkg-cross 3.0.0
and xapt gains a Depends: dpkg-cross (<= 3) immediately Wheezy is
released. dpkg-cross 3.0.0 would then have a Breaks: xapt and xapt
would be removed once dpkg-cross 3.0.0 arrived in unstable, possibly
not until after Wheezy +1, depending on the resolution of -dev
MultiArch package issues. To allow final removal of the transitional
dpkg-cross 3.0.0 and closure of this bug, dpkg-dev would adopt the
arch-specific metadata in dpkg-cross 3.0.0. Packages which currently
rely on package-specific metadata in /etc/dpkg-cross/cross* will have
to be patched to continue any cross-building support before dpkg-cross
can finally be removed.

The rest of this problem comes down to individual packages:

0: packages using custom config scripts instead of pkg-config

1: packages which have m4 macros which don't handle cross-building
cleanly, e.g. AC_TRY_RUN without fallbacks.

I think having dpkg-cross 3.0.0 is a useful interim stage which allows
the problems with -dev MultiArch packages to be resolved after Wheezy,
allows packages to migrate whilst retaining what cross-build support we
already have and provides a somewhat smooth path to eventual removal of
dpkg-cross.

Therefore, I think this bug will need to remain open, unless dpkg
maintainers do not wish to integrate the cross architecture-specific
metadata at all. (This data does not change until a new port is
accepted by dpkg or an old port removed, at which point it is just a
single file addition/removal containing data provided by the porters.)

e.g. for armel:
ac_cv_c_bigendian=no
ac_cv_c_char_unsigned=yes
ac_cv_sizeof_long_long=8
ac_cv_sizeof_unsigned_long_long=8
ac_cv_sizeof_long=4

> > The main issue unresolved in this bug report is the mapping
> > of /usr/lib/foo.so to /usr/arm-linux-gnu/lib/foo.so for packages that do
> > not use pkg-config (e.g. I'm having upstream problems trying to
> > configure a package that build-depends on Postgres and ODBC using
> > pg_config and iodbc-config respectively).
>
> This should be solved by making those packages multi-arch ready.

Yes, this part of it is resolved as far as dpkg is concerned and the
work is now with package maintainers to implement MultiArch support but
there remains the issues around MultiArch and -dev packages which may
yet require some dpkg support - and thereby block this bug.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Wookey 07-22-2012 05:01 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
+++ Neil Williams [2012-07-22 17:05 +0100]:
> On Wed, 18 Jul 2012 19:11:38 +0200
> Guillem Jover <guillem@debian.org> wrote:
>
> > So, was checking this (and also the dpkg roadmap) and was wondering what
> > else is still missing to be merged from dpkg-cross? If the only problem
> > is the listed below, then it'd seem this bug has been resolved and it
> > can be closed.
>
> One unresolved issue is the cache values and architecture support:
> where to put the cross- config settings currently implemented
> in /etc/dpkg-cross/cross* which pass the architecture-specific values
> to autotools projects. CC'ing debian-embedded for more input on
> that.

> The rest of this problem comes down to individual packages:
>
> 0: packages using custom config scripts instead of pkg-config
>
> 1: packages which have m4 macros which don't handle cross-building
> cleanly, e.g. AC_TRY_RUN without fallbacks.

It was sugested at the multiarch-cross BOF at debconf this year that we
create a 'crossbuild-support' package to take over these various glue
functions from dpkg-cross. That could just stay named 'dpkg-cross' for
simplicity but if we are going to drop all the cross-conversion
functionality and add a load of other stuff, a name change makes
sense.

> Therefore, I think this bug will need to remain open, unless dpkg
> maintainers do not wish to integrate the cross architecture-specific
> metadata at all. (This data does not change until a new port is
> accepted by dpkg or an old port removed, at which point it is just a
> single file addition/removal containing data provided by the porters.)

I don't think that dpkg is the right place for this data. We want to
be able to update it easily without having to mess with important
things like dpkg. The core cross functionality is now in dpkg and apt.
We should discuss where remaining stuff like autoconf cache variables,
triplet-prefixed commands like <triplet>-pkg-config and
<triplet>-config scripts, cross-build-essential package lists and the
like should live, but I don't currently see good arguments to put any
more of it into dpkg.

If we are agreed on that then this bug is indeed closed.

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120722170105.GC16745@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120722170105.GC16745@stoneboat.aleph1.co.uk

Guillem Jover 07-22-2012 05:23 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
Hi!

On Sun, 2012-07-22 at 18:01:05 +0100, Wookey wrote:
> +++ Neil Williams [2012-07-22 17:05 +0100]:
> > On Wed, 18 Jul 2012 19:11:38 +0200
> > Guillem Jover <guillem@debian.org> wrote:
> >
> > > So, was checking this (and also the dpkg roadmap) and was wondering what
> > > else is still missing to be merged from dpkg-cross? If the only problem
> > > is the listed below, then it'd seem this bug has been resolved and it
> > > can be closed.
> >
> > One unresolved issue is the cache values and architecture support:
> > where to put the cross- config settings currently implemented
> > in /etc/dpkg-cross/cross* which pass the architecture-specific values
> > to autotools projects. CC'ing debian-embedded for more input on
> > that.
>
> > The rest of this problem comes down to individual packages:
> >
> > 0: packages using custom config scripts instead of pkg-config
> >
> > 1: packages which have m4 macros which don't handle cross-building
> > cleanly, e.g. AC_TRY_RUN without fallbacks.
>
> It was sugested at the multiarch-cross BOF at debconf this year that we
> create a 'crossbuild-support' package to take over these various glue
> functions from dpkg-cross. That could just stay named 'dpkg-cross' for
> simplicity but if we are going to drop all the cross-conversion
> functionality and add a load of other stuff, a name change makes
> sense.

Such package sounds like a good idea indeed, but I'd really like if any
glue required there would end up being mere environment variable
settings (like appropriate CC for cross-building for example), symlinks
for cross tools, the cache files or at most a tiny wrapper for
dpkg-buildpackage passing correct options. Anything else should be
integrated back in the lower layers IMO (if it makes sense and the
solutions are “generic enough”).

> > Therefore, I think this bug will need to remain open, unless dpkg
> > maintainers do not wish to integrate the cross architecture-specific
> > metadata at all. (This data does not change until a new port is
> > accepted by dpkg or an old port removed, at which point it is just a
> > single file addition/removal containing data provided by the porters.)

> > e.g. for armel:
> > ac_cv_c_bigendian=no
> > ac_cv_c_char_unsigned=yes
> > ac_cv_sizeof_long_long=8
> > ac_cv_sizeof_unsigned_long_long=8
> > ac_cv_sizeof_long=4

Something that has crossed my mind in the recent past is that cputable
has most of this data, but not all, and it could make sense to add
more information so that the architecture ABI is crystal clear from
the tables alone. dpkg-cross or crossbuild-support or whatever could
then generate an autoconf cache file at build time from the dpkg tables
for example. Because I'd assume there's other cached values that will
end up there and those would certainly not be appropriate for dpkg.

> I don't think that dpkg is the right place for this data. We want to
> be able to update it easily without having to mess with important
> things like dpkg. The core cross functionality is now in dpkg and apt.
> We should discuss where remaining stuff like autoconf cache variables,
> triplet-prefixed commands like <triplet>-pkg-config and
> <triplet>-config scripts, cross-build-essential package lists and the
> like should live, but I don't currently see good arguments to put any
> more of it into dpkg.

Except for my comments above, I tend to agree with this.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120722172344.GA20352@gaara.hadrons.org">http://lists.debian.org/20120722172344.GA20352@gaara.hadrons.org

Neil Williams 07-22-2012 05:26 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 22 Jul 2012 18:01:05 +0100
Wookey <wookey@wookware.org> wrote:

> +++ Neil Williams [2012-07-22 17:05 +0100]:
> > One unresolved issue is the cache values and architecture support:
> > where to put the cross- config settings currently implemented
> > in /etc/dpkg-cross/cross* which pass the architecture-specific values
> > to autotools projects. CC'ing debian-embedded for more input on
> > that.
>
> It was sugested at the multiarch-cross BOF at debconf this year that we
> create a 'crossbuild-support' package to take over these various glue
> functions from dpkg-cross. That could just stay named 'dpkg-cross' for
> simplicity but if we are going to drop all the cross-conversion
> functionality and add a load of other stuff, a name change makes
> sense.

OK. I don't mind what the package name is, as long as it Breaks: xapt.
If it's not dpkg-cross, it will also need to Conflict: dpkg-cross

The cross-conversion functionality can only be dropped once the
"critical mass" of -dev packages are implemented.

> > Therefore, I think this bug will need to remain open, unless dpkg
> > maintainers do not wish to integrate the cross architecture-specific
> > metadata at all. (This data does not change until a new port is
> > accepted by dpkg or an old port removed, at which point it is just a
> > single file addition/removal containing data provided by the porters.)
>
> I don't think that dpkg is the right place for this data.

The architecture-specific data? Is that really subject to change? True
the package-specific stuff is going to change and is not useful in
dpkg, but once a port has been accepted, the chances of the size of a
long long being changed are slim (and a serious problem).

> We want to
> be able to update it easily without having to mess with important
> things like dpkg.

True - for the package-specific stuff. Equally, the package-specific
stuff could actually be patched into the relevant packages which is a
better place for it - eventually.

> The core cross functionality is now in dpkg and apt.

with the sole exception of the size of a long long for DEB_HOST_ARCH
etc.

> We should discuss where remaining stuff like autoconf cache variables,
> triplet-prefixed commands like <triplet>-pkg-config and
> <triplet>-config scripts, cross-build-essential package lists and the
> like should live, but I don't currently see good arguments to put any
> more of it into dpkg.

The package-specific stuff does not need to be lumped in with the truly
architecture-specific variables.

Most of the package-specific cache variables are not also
architecture-specific, separating those out means less files need
updates and if we do get the package-specific cache values into the
packages, the whole cache problem becomes more manageable.

This is a long-term goal, it will take until Wheezy+1 to even get that
"critical mass" of -dev MultiArch packages.

> If we are agreed on that then this bug is indeed closed.

So is it worth separating out the architecture-specific cache values?

It's not easy to do until other changes are in place but I think it
should be done.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Neil Williams 07-22-2012 05:35 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 22 Jul 2012 19:23:44 +0200
Guillem Jover <guillem@debian.org> wrote:

> On Sun, 2012-07-22 at 18:01:05 +0100, Wookey wrote:
> > It was sugested at the multiarch-cross BOF at debconf this year that we
> > create a 'crossbuild-support' package to take over these various glue
> > functions from dpkg-cross. That could just stay named 'dpkg-cross' for
> > simplicity but if we are going to drop all the cross-conversion
> > functionality and add a load of other stuff, a name change makes
> > sense.
>
> Such package sounds like a good idea indeed, but I'd really like if any
> glue required there would end up being mere environment variable
> settings (like appropriate CC for cross-building for example), symlinks
> for cross tools, the cache files or at most a tiny wrapper for
> dpkg-buildpackage passing correct options. Anything else should be
> integrated back in the lower layers IMO (if it makes sense and the
> solutions are “generic enough”).

OK.

> > > e.g. for armel:
> > > ac_cv_c_bigendian=no
> > > ac_cv_c_char_unsigned=yes
> > > ac_cv_sizeof_long_long=8
> > > ac_cv_sizeof_unsigned_long_long=8
> > > ac_cv_sizeof_long=4
>
> Something that has crossed my mind in the recent past is that cputable
> has most of this data, but not all, and it could make sense to add
> more information so that the architecture ABI is crystal clear from
> the tables alone.

That sounds like a very useful goal. Thanks.

> dpkg-cross or crossbuild-support or whatever could
> then generate an autoconf cache file at build time from the dpkg tables
> for example. Because I'd assume there's other cached values that will
> end up there and those would certainly not be appropriate for dpkg.

OK.

> > I don't think that dpkg is the right place for this data. We want to
> > be able to update it easily without having to mess with important
> > things like dpkg. The core cross functionality is now in dpkg and apt.
> > We should discuss where remaining stuff like autoconf cache variables,
> > triplet-prefixed commands like <triplet>-pkg-config and
> > <triplet>-config scripts, cross-build-essential package lists and the
> > like should live, but I don't currently see good arguments to put any
> > more of it into dpkg.
>
> Except for my comments above, I tend to agree with this.

I'd be happy if this bug is closed with an upload of dpkg which extends
the cputable data to complete the ABI declarations with the
architecture-specific values from which dpkg-cross / replacement can
derive the cache values.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Guillem Jover 07-22-2012 05:46 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 2012-07-22 at 18:35:16 +0100, Neil Williams wrote:
> I'd be happy if this bug is closed with an upload of dpkg which extends
> the cputable data to complete the ABI declarations with the
> architecture-specific values from which dpkg-cross / replacement can
> derive the cache values.

Ok, perfect, then I'll prepare and queue this for 1.17.x.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120722174608.GA21373@gaara.hadrons.org">http://lists.debian.org/20120722174608.GA21373@gaara.hadrons.org

shawn 07-22-2012 05:52 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 2012-07-22 at 19:46 +0200, Guillem Jover wrote:
> On Sun, 2012-07-22 at 18:35:16 +0100, Neil Williams wrote:
> > I'd be happy if this bug is closed with an upload of dpkg which extends
> > the cputable data to complete the ABI declarations with the
> > architecture-specific values from which dpkg-cross / replacement can
> > derive the cache values.
>
> Ok, perfect, then I'll prepare and queue this for 1.17.x.
Will this allow me to query the the 64-bit complement of a 32-bit arch,
and visa versa?

I would be using this for a patch making dpkg cross-building work with
gcc's multilib in gcc-defaults package.
>
> thanks,
> guillem
>
>


--
-Shawn Landden


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1342979539.5910.191.camel@shawn-ssd

Guillem Jover 07-22-2012 07:45 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 2012-07-22 at 10:52:19 -0700, shawn wrote:
> On Sun, 2012-07-22 at 19:46 +0200, Guillem Jover wrote:
> > On Sun, 2012-07-22 at 18:35:16 +0100, Neil Williams wrote:
> > > I'd be happy if this bug is closed with an upload of dpkg which extends
> > > the cputable data to complete the ABI declarations with the
> > > architecture-specific values from which dpkg-cross / replacement can
> > > derive the cache values.
> >
> > Ok, perfect, then I'll prepare and queue this for 1.17.x.

> Will this allow me to query the the 64-bit complement of a 32-bit arch,
> and visa versa?

No, not really. The main problem is that there's cases where there's
no obvious 1:1 mapping, take i386/x32/amd64 or arm/armel/armhf/arm64,
or mips where there's three ABIs, etc. And I don't think this is
generally useful anyway, less so now with multiarch when multilib
packages will be disappearing.

> I would be using this for a patch making dpkg cross-building work with
> gcc's multilib in gcc-defaults package.

I think I've mentioned this before, but gcc already has (and needs)
knowledge about the multilib “pairs” and as such it makes sense to
keep that knowdlege localized there.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120722194508.GA22372@gaara.hadrons.org">http://lists.debian.org/20120722194508.GA22372@gaara.hadrons.org

shawn 07-22-2012 08:47 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 2012-07-22 at 21:45 +0200, Guillem Jover wrote:
> On Sun, 2012-07-22 at 10:52:19 -0700, shawn wrote:
> > On Sun, 2012-07-22 at 19:46 +0200, Guillem Jover wrote:
> > > On Sun, 2012-07-22 at 18:35:16 +0100, Neil Williams wrote:
> > > > I'd be happy if this bug is closed with an upload of dpkg which extends
> > > > the cputable data to complete the ABI declarations with the
> > > > architecture-specific values from which dpkg-cross / replacement can
> > > > derive the cache values.
> > >
> > > Ok, perfect, then I'll prepare and queue this for 1.17.x.
>
> > Will this allow me to query the the 64-bit complement of a 32-bit arch,
> > and visa versa?
>
> No, not really. The main problem is that there's cases where there's
> no obvious 1:1 mapping, take i386/x32/amd64 or arm/armel/armhf/arm64,
> or mips where there's three ABIs, etc. And I don't think this is
> generally useful anyway, less so now with multiarch when multilib
> packages will be disappearing.
>
> > I would be using this for a patch making dpkg cross-building work with
> > gcc's multilib in gcc-defaults package.
>
> I think I've mentioned this before, but gcc already has (and needs)
> knowledge about the multilib “pairs” and as such it makes sense to
> keep that knowdlege localized there.
Well that was the idea. How would you suggest I approach this (patch
attached) that pushes the logic out to the gcc-defaults/multilib stuff.
It does not include the needed binutils symlinks. Suggestions on where
those should go is wanted.

Where is this logic that i can tap into for creating these symlinks if
not in dpkg?
>
> thanks,
> guillem


--
-Shawn Landden

shawn 07-22-2012 08:58 PM

Bug#180128: state of integration of dpkg-cross into dpkg
 
On Sun, 2012-07-22 at 13:47 -0700, shawn wrote:
> On Sun, 2012-07-22 at 21:45 +0200, Guillem Jover wrote:
> > No, not really. The main problem is that there's cases where there's
> > no obvious 1:1 mapping, take i386/x32/amd64 or arm/armel/armhf/arm64,
> > or mips where there's three ABIs, etc. And I don't think this is
> > generally useful anyway, less so now with multiarch when multilib
> > packages will be disappearing.
I guess I already have to rework the calls into dpkg-architecture to
work with this. I wasn't thinking about these cases. And since this is,
well---a hack until much-arch takes over (does this really make sense to
use full cross-compilers instead of multilib?) it would be OK to hard
code some of this logic into the gcc-default/multilib defaults packages
so that we can make it work now with the same api that the
cross-compilers will provide--making the transition in the future
easier.

Again, not sure which package should provide binutils symlinks. Maybe a
new binutils-multilib package? This is a problem all the cross-compiler
stuff is going to have to address as well. not that much stuff, but as
its in the path maybe better to avoid polluting with stuff like putting
it in the binutils package, and similar.
> >
> > > I would be using this for a patch making dpkg cross-building work with
> > > gcc's multilib in gcc-defaults package.
>
> Where is this logic that i can tap into for creating these symlinks if
> not in dpkg?
> >
> > thanks,
> > guillem
>
>


--
-Shawn Landden


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1342990728.5910.199.camel@shawn-ssd


All times are GMT. The time now is 03:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.