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 E37921387FD for ; Wed, 26 Mar 2014 06:07:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1D00E0A9E; Wed, 26 Mar 2014 06:07:51 +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 BA317E0A90 for ; Wed, 26 Mar 2014 06:07:50 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B5ABC33FD37 for ; Wed, 26 Mar 2014 06:07:49 +0000 (UTC) From: Mike Frysinger To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] crossdev and multilib interference Date: Wed, 26 Mar 2014 02:07:56 -0400 Message-ID: <1655097.HpObVGm6RL@vapier> Organization: wh0rd.org User-Agent: KMail/4.12.3 (Linux/3.13.0; KDE/4.12.3; x86_64; ; ) In-Reply-To: References: <53208139.2040509@gentoo.org> <1394640392.7647.18.camel@rook> 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="nextPart1574210.jzfyY0DTZ1"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Archives-Salt: 8d73a3d1-3214-4ada-93ed-4a201eedd33f X-Archives-Hash: f247151bfcd9f9bfb269e1a2fe0eff64 --nextPart1574210.jzfyY0DTZ1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sun 16 Mar 2014 04:50:33 Greg Turner wrote: > cmake-multilib.eclass, for example, breaks in mind-warpingly subtle a= nd > confusing ways on USE=3D"abi_x86_{32,64}" multilib hosts with > i686-pc-linux-gnu crossdev installed (when combined with some other i= ssues > in that eclass, this results in correct qawarns about ignored ldflags= on > devel profiles -- an ugly work-around is in my overlay, but I'm not h= appy > with it, so it's been languishing in my rainy-day todo queue. I'd be= > thrilled to see a solution to the underlying problem, so I don't feel= > compelled to salvage the ugly parts). cmake is completely broken when it comes to library searching and multi= lib and=20 cross-compiling. it will happily look in hardcoded / paths to test for= the=20 existence of files as well as directly execute `pkg-config`. it's a gr= eat=20 example of people saying "autotools is crap, so let's invent our own ki= nd of=20 crap and ignore lessons learned". this isn't the fault of cmake eclass= es, but=20 it'd be nice if we could someone standardize the hacks in there so we d= on't=20 have to duplicate across ebuilds. just look at how cmake internally utilizes CMAKE_FIND_ROOT_PATH. or gr= ep=20 "pkg-config" in /usr/share/cmake/. or look at find_library usage in cm= ake=20 macros. it's fundamentally screwed up right now :(. > As for how to fix it, if foo-bar-baz-quux crossdev targets are at > ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in > ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that,= seems > perfectly reasonable... heck, pure speculation, but it might even > noticeably speed up day-to-day $PATH searching on systems with lots o= f > crossdev targets installed. if they're in $PATH, then the exact location is irrelevant. they need = not be=20 in /usr/bin to cause a problem. if they're not in $PATH, then you're b= reaking=20 the cross-compilers and that is unacceptable. putting CHOST things in /usr/CTARGET is incorrect. /usr/CHOST/CTARGET/= is for=20 hosting helper programs specific to CTARGET that run on CHOST. =2Dmike --nextPart1574210.jzfyY0DTZ1 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) iQIcBAABAgAGBQJTMm68AAoJEEFjO5/oN/WBPk4P+wY7dbA9aHB2I1h9vc7EK7/m Svrd4xlYw1asi08h+8o7CIe70YOtldNoF/iFlCvclvnEaPGN2/B6QnFZKi3GYHTf JvGc9DAKCgfU2LDhYh8zeHZO8B7hvnKvelMTzSsMl/Kp0rR7eF5y0BIINCxCi/Ox T7TGsoQbnmDuGj12k5xgaDY5WkArNSyzMTC5y8CJAGoSXeOJzBs0f+ikVGnJ9bZo PAVRWO/7Ao9PNEPaSqbXhHpLCU4oj4FfcvoExYRi4V55/dmFpCK0lbjSVBncOE+m 280VC0UcZsJ50PRZQ4w94Uc13HUeMS8oT5UhnCe2IFgAdr8xDlRmp9pXuwZg/4MJ YqiEwdib2ww9lCcr3mcKSKtoxE1qw9hzg6JcCBdmwHi4gpTXl/4Dg8nTtsQPRUq8 XOcloD+HLolLfbtTdQ8a2Of/stglSkz2zIgZBC9WWuETm3BXT8xc6VnO3tEgfDua bhnLQecjN4DLl5C0iKSNgVr7KzSkvzTZJdh/n1G1iPrnoz4Up+Gk+TcFwcZkUcV+ WuA9px3jvsi7LflTYN5xJQfyFvcoQIk67rUrmPmCXIs9kLS/DmF9b0tMYgv9pP3i SIS7zvd/aap7fwnsClQZlGCrXSSJYemw1gInhuFlt/BWPa5fNnVd84o9yveAwqne qEkm1OS9t8vTQM3X1BZA =ZpFh -----END PGP SIGNATURE----- --nextPart1574210.jzfyY0DTZ1--