From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PaNZS-0001Nr-Va for garchives@archives.gentoo.org; Wed, 05 Jan 2011 07:14:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 07645E06A1 for ; Wed, 5 Jan 2011 07:14:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 42537E050C for ; Wed, 5 Jan 2011 07:04:07 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 93F9B1B4038; Wed, 5 Jan 2011 07:04:06 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-embedded@lists.gentoo.org Subject: Re: [gentoo-embedded] e2fsprogs checking for blkid_get_cache in -lblkid... no Date: Wed, 5 Jan 2011 02:03:17 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.37-rc5; KDE/4.5.2; x86_64; ; ) Cc: Patrice Tisserand , Kfir Lavi References: <201101041359.25616.vapier@gentoo.org> <4D239B6A.4090600@wyplay.com> In-Reply-To: <4D239B6A.4090600@wyplay.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3065605.14bk11gqUo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101050203.19189.vapier@gentoo.org> X-Archives-Salt: e2c00cb0-2dbb-428d-bab5-a9c95bfd5cc2 X-Archives-Hash: 8aa221827193edcd956a0625c26320d9 --nextPart3065605.14bk11gqUo Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday, January 04, 2011 17:12:58 Patrice Tisserand wrote: > On 01/04/2011 07:59 PM, Mike Frysinger wrote: > > On Tuesday, January 04, 2011 04:02:59 Patrice Tisserand wrote: > >> Does adding -L /tmp/target_root/lib -L /tmp/target_root/usr/lib > >> -Wl,-rpath-link,/tmp/target_root/lib > >> -Wl,-rpath-link,/tmp/target_root/usr/lib to LDFLAGS could not be an > >> alternative ? > >=20 > > no. that's broken by design. >=20 > Thanks for your answer, I have found the following sentence in gentoo > embedded handbook: > """The common convention is to use your /usr/CTARGET/ tree as your > sysroot as the include/library directories in this tree are already > encoded into the gcc cross-compiler for searching. You could use another > directory and then add custom -I/-L paths to your CPPFLAGS/LDFLAGS, but > this has historically proven to be problematic. Yes, it works most of > the time, but the corner cases are why this method is discouraged. In > the embedded handbook, we'll assume you're using the sysroot as your > development ROOT. > """ > Do you know where I can find references about these corner cases ? perhaps ive cited examples on this list in the past, but i dont recall. i'= ll=20 just refer to Bug 347489 and mention the same issue with like=20 curses/bash/screen off the top of my head. > Also how can I handle creating 2 different target rootfs with different > libraries versions but using the same cross-compilation toolchain? > Do I need to duplicate environment or is there some tips ? i dont know why you'd do this, but the cleanest approach today would be to= =20 create a new cross-compiler toolchain with a slightly different vendor so y= ou=20 get unique paths. i imagine it'd be possible to also take the default gcc= =20 specs, tweak the sysroot arg in it, and export the GCC_SPECS env var, but i= t=20 could get messy as you'd have to remember what you have your env set to. =2Dmike --nextPart3065605.14bk11gqUo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJNJBe3AAoJEEFjO5/oN/WBAt8P/i8G80JgWSoxlOTg4jTzWRjA kV0zMwy6HhT7B4b1P+vSpKE39u2pXWkZTugv2ggtf/BUSui6kk1Fuba/JXSmoHPF kfd+5Eqrx62l2dasToJXHvjV7OAYlsCq56qb3rjxp21SwMby1/j9cFrQUhz8KSqo kXZswmkZ6Rb4aVJ4d9RtW09w4+t+lsCsefUVdzDBpR5UsP/icJnlGv8QeRQ3GTfS t52u1wk2gh84aYoaa4uTBJKqd1Bf3EViT/OU7U8cjGKyS7cp2WK2EcH/pvYB+G6E nGOORJ6cEAr7ziorXvGHwUHwRhnp16yipqeK75fRNTWt2Tnsq/B34GPNRTlJ3OF5 IAjRz890yeSnqFuRPVnuonHm2GcVon5d1j7tBZWnsMH4KJXlAUzKmcH47GwPEV5F itJB7C5s2s1SrBJUCv2koRIiPzgT2/zgWJnHSLITh0p7R+ORi9oV3zsHEA4ljf/v qIkHiiOVZvXLenANbggHgNwHm/MLl/Wbitpg4p5hAS0jNIbL9jzCkjo8vSO8HE8h vDBwewCvt/3ncM50S+GLNpADzHZd8LIsCWNoU4ntL8Mzj6d6tgQxwHu9tj1XgN/G P0e8Xy0obDM60bJViVnjjRj9Bz1yvf9PTrQiPI1HQ+0//HOFPoMJr18KykBrsCL+ Q5X0K9Hg55borG4w50UJ =qZOY -----END PGP SIGNATURE----- --nextPart3065605.14bk11gqUo--