Re: [gentoo-dev] crossdev and multilib interference

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

On Thu 27 Mar 2014 15:31:31 Michał Górny wrote:
> Dnia 2014-03-27, o godz. 10:23:30 Mike Frysinger napisał(a):
> > On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
> > > Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
> > > > On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> > > > > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > > > > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > > > > > (2) use tuples with loaded vendor fields to reduce the chance of
> > > > > > > collisions. e.g. having an ABI=amd64 system use
> > > > > > > i686-gentoo%multilib-linux-gnu instead of i686-pc-linux-gnu
> > > > > > > would
> > > > > > > defeat any automatic path searches.
> > > > > > 
> > > > > > this patch keeps the status quo.  although the status quo is
> > > > > > broken,
> > > > > > but
> > > > > > we
> > > > > > can sort that out independently.
> > > > > 
> > > > > Except that it breaks stuff that is installed at the point and comes
> > > > > with no plan of cleaning up the resulting mess.
> > > > 
> > > > such as ... ?  vague statements can't be addressed.
> > > 
> > > Such as all the builds that use ${CHOST}-foo currently. If you change
> > > CHOST, our users will have to find and rebuild all packages that
> > > install ${CHOST}-foos or otherwise random breakage will happen.
> > 
> > again, please give a concrete example
> 
> glib -- ${CHOST}-gdk-pixbuf-query-loaders (used in gnome2-utils.eclass)
> gpg-error -- ${CHOST}-gpg-error-config
> libgcrypt -- ${CHOST}-libgcrypt-config
> llvm -- ${CHOST}-llvm-config
> pango -- ${CHOST}-pango-querymodules
> 
> If you change CHOST, all invocations of those tools will fail randomly
> until the respective packages are rebuilt. In some cases it will call
> the wrong variant (resulting in borked output), in other it will call
> non-existing tool.

so the *-config scripts.  we already know these are broken, not only from a 
conceptual pov, but from real world too -- it relies on CHOST being unique.  
but this needs to be sorted out anyways since the current system isn't working 
(independent of crossdev usage), and perhaps that means breaking now so things 
are cleaner in the future.

for the gnupg projects, we've already disabled -L paths from being emitted, so 
the variants will still work (gpg-error-config will give the same answer as 
$CHOST-gpg-error-config wrt --libs and such).

the llvm/gdk/pango logic would probably break.  we had been looking at 
rewriting the gdk/pango stuff to not require direct execution (since this 
logic completely fails when cross-compiling) in Chromium OS, but that's been 
on the back burner for a while.  instead, we hand generate/mung the pango 
modules cache file, and we've punted gtk/gdk from the image, so we don't care 
it is broken.

the pango stuff is also broken because it uses /etc/pango/$CHOST in an attempt 
to get an ABI unique path.  we probably should change that to /etc/pango/$ABI 
or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk cache 
does.  the gnome guys would know best.

the llvm impact doesn't look terribly big as very few things use it.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]