From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C41601387FD for ; Fri, 28 Mar 2014 06:33:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BAC12E08BD; Fri, 28 Mar 2014 06:33:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A3644E0ACD for ; Fri, 28 Mar 2014 06:33:03 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A117333FD85; Fri, 28 Mar 2014 06:33:02 +0000 (UTC) From: Mike Frysinger To: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] crossdev and multilib interference Date: Fri, 28 Mar 2014 02:33:09 -0400 Message-ID: <2318673.p2B772y41A@vapier> Organization: wh0rd.org User-Agent: KMail/4.12.3 (Linux/3.13.0; KDE/4.12.3; x86_64; ; ) In-Reply-To: <20140327153131.3601bf01@pomiot.lan> References: <53208139.2040509@gentoo.org> <2838880.tI3meRIIup@vapier> <20140327153131.3601bf01@pomiot.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2735571.PYIrCIgqmk"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Archives-Salt: 1e25c872-6aa3-4e47-9b9f-84f96321a690 X-Archives-Hash: daf6b05305f9d6712e2b071f59fe6627 --nextPart2735571.PYIrCIgqmk Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thu 27 Mar 2014 15:31:31 Micha=C5=82 G=C3=B3rny wrote: > Dnia 2014-03-27, o godz. 10:23:30 Mike Frysinger napisa=C5=82(a): > > On Thu 27 Mar 2014 10:10:07 Micha=C5=82 G=C3=B3rny wrote: > > > Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisa=C5=82(a):= > > > > On Thu 27 Mar 2014 07:51:32 Micha=C5=82 G=C3=B3rny wrote: > > > > > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisa=C5=82= (a): > > > > > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote: > > > > > > > (2) use tuples with loaded vendor fields to reduce the ch= ance of > > > > > > > collisions. e.g. having an ABI=3Damd64 system use > > > > > > > i686-gentoo%multilib-linux-gnu instead of i686-pc-linux-g= nu > > > > > > > would > > > > > > > defeat any automatic path searches. > > > > > >=20 > > > > > > this patch keeps the status quo. although the status quo i= s > > > > > > broken, > > > > > > but > > > > > > we > > > > > > can sort that out independently. > > > > >=20 > > > > > Except that it breaks stuff that is installed at the point an= d comes > > > > > with no plan of cleaning up the resulting mess. > > > >=20 > > > > such as ... ? vague statements can't be addressed. > > >=20 > > > Such as all the builds that use ${CHOST}-foo currently. If you ch= ange > > > CHOST, our users will have to find and rebuild all packages that > > > install ${CHOST}-foos or otherwise random breakage will happen. > >=20 > > again, please give a concrete example >=20 > glib -- ${CHOST}-gdk-pixbuf-query-loaders (used in gnome2-utils.eclas= s) > gpg-error -- ${CHOST}-gpg-error-config > libgcrypt -- ${CHOST}-libgcrypt-config > llvm -- ${CHOST}-llvm-config > pango -- ${CHOST}-pango-querymodules >=20 > If you change CHOST, all invocations of those tools will fail randoml= y > 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 fr= om a=20 conceptual pov, but from real world too -- it relies on CHOST being uni= que. =20 but this needs to be sorted out anyways since the current system isn't = working=20 (independent of crossdev usage), and perhaps that means breaking now so= things=20 are cleaner in the future. for the gnupg projects, we've already disabled -L paths from being emit= ted, so=20 the variants will still work (gpg-error-config will give the same answe= r as=20 $CHOST-gpg-error-config wrt --libs and such). the llvm/gdk/pango logic would probably break. we had been looking at=20= rewriting the gdk/pango stuff to not require direct execution (since th= is=20 logic completely fails when cross-compiling) in Chromium OS, but that's= been=20 on the back burner for a while. instead, we hand generate/mung the pan= go=20 modules cache file, and we've punted gtk/gdk from the image, so we don'= t care=20 it is broken. the pango stuff is also broken because it uses /etc/pango/$CHOST in an = attempt=20 to get an ABI unique path. we probably should change that to /etc/pang= o/$ABI=20 or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk ca= che=20 does. the gnome guys would know best. the llvm impact doesn't look terribly big as very few things use it. =2Dmike --nextPart2735571.PYIrCIgqmk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJTNRelAAoJEEFjO5/oN/WBDbAQANuQOA7ZUyaKk9KBMgEJ3DMq NAn6TrMuK5WfatLmS3wO2UNINyLRT+I69tNkeo47z3VtUf8AD5UORiGU445EFxHy LuF0VuNDZOd5gd0f1JZfmSPpO3AP1yb7O55ssdN41U4YzctHI5mNNJ+wBS8U9lcx d+sGaRD816EW/uqo6NgK0WunXxzeCpmSgoiGapLbBpOr/dR0hkBE5FsSxfcpyEoP 8UoQVjzHZJcjBbLfQbj4XSzbjAYASJ/1mOanf1c448P++O98L5D4wuIpvG3dhYU6 HovccLQdzrhNVnADF5rwy/Xz51x/46V9v0E6TU7o1+XEXFG0tbiC8Yucs/a9WfS/ Yi6PK+2hdQvlpC+RVEq8W4bQri5QH+nxAvwe6Y6I1kmHt2OmVg7/5dPF8r+A4eG6 1jf8Q1x8JoMPfknQ76nq/MdYmnZ6TkaDYZI+VjPfGxH2aVs2Pj6qlxtlUnBdUTZu YSrb3ytsP9us+td5rqz0kw7ZqjmLSOm7CXkMFIVH44ukQo+4HT7OsHK5n2tNt7QE Jxi3sd48qO/DdW04ZZrZLERvKAzAVaMTUx/VrQuim9RD8vTsS7+RaYlFsthHpF/d QI1hRv7T71sK9Ac0l9j0T0KjROb08wFKTeMhiSsZxTWHAchmGGPw6ElTZIfNt5ry jPzghiECXCyB7ejq/oFA =jUfR -----END PGP SIGNATURE----- --nextPart2735571.PYIrCIgqmk--