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 87C5F138010 for ; Thu, 11 Oct 2012 03:38:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 109F4E0077; Thu, 11 Oct 2012 03:38:00 +0000 (UTC) Received: from malth.us (malth.us [75.147.143.249]) by pigeon.gentoo.org (Postfix) with ESMTP id B642DE0123 for ; Thu, 11 Oct 2012 03:37:29 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by malth.us (Postfix) with ESMTP id CB1FA40CA51F for ; Wed, 10 Oct 2012 20:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at malth.us Received: from malth.us ([127.0.0.1]) by localhost (malth.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l51D3hfFJ+o for ; Wed, 10 Oct 2012 20:37:26 -0700 (PDT) Received: from [192.168.0.175] (moneypit.hq [192.168.0.175]) by malth.us (Postfix) with ESMTPSA id 5305740CA51E for ; Wed, 10 Oct 2012 20:37:26 -0700 (PDT) Message-ID: <50763EF6.7000507@malth.us> Date: Wed, 10 Oct 2012 20:37:26 -0700 From: "Gregory M. Turner" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath References: <506F9C61.3020500@malth.us> <506FE22D.6000300@malth.us> <201210091726.49675.vapier@gentoo.org> In-Reply-To: <201210091726.49675.vapier@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 6325b0c4-3b90-435c-b8f4-c6eaab900c6d X-Archives-Hash: ccf5c346f4cb785bd4930da64d3ece2e On 10/9/2012 2:26 PM, Mike Frysinger wrote: > On Saturday 06 October 2012 03:47:57 Gregory M. Turner wrote: >> My god, I am a horrible self-editor. Sorry. Please ignore the magnum >> opus above and allow me to try again. >> >> In dev-lang/python*, we use >> >> append-ldflags '-L.' >> >> to ensure linking is performed against the built libpython.so in-tree, >> rather than than in the one in $(libdir). But, this doesn't work if >> LDFLAGS contains "-L$(libdir)". > > well, some notes here ... > > for users: putting -L is wrong. it changes the meaning of > "system paths" when it comes to searching for linking by elevating it to "user > specified path". imo, you should be fixing the source rather than the symptom. > > for packagers: using -L$(libdir) is almost always wrong and pointless. the > toolchain itself knows the proper system path to search for libraries to link > against, and when you cross-compile, the --libdir you specify to configure is > not going to be valid when dereferenced on the build system. Agreed on these points. Not until we combine the doubly broken circumstances of (1) User specified -L/usr/$(libdir) in LDPATH and (2) an ebuild that puts -L. into LDPATH to fix Makefile recipes that appear more-or-less broken, do we get this conflict. This leads to a certain odor of "unsupportable circumstances" which, I must admit, makes me slightly uncomfortable trying to fix it. Breaking this down: (1) is worse than (2), but it does have some quasi-legitimate usages. For example, prefix bootstrap does this (or used to), as do many of the crossdev-wrapper scripts. I've also resorted to such usage, myself, when repairing a prefix after I've broken its compiler. These cases don't really seem completely "correct" or "incorrect" -- about the best I can say for them it is that they are mostly efficacious, but prone to problems. As for (2)... meh. LDFLAGS, to my thinking, means something like: "Use these guidelines and parameters for linking, in preference to the default guidelines that the build process would normally use." LDFLAGS coming from make.conf have a slightly different meaning, I guess, but the gist of it is the same. So technically speaking, LDFLAGS="-L. ${LDFLAGS}" or similar is not a complete abomination. Still... I don't like it. If the Makefiles are building against libraries expected to be in ${PWD}, it seems to me that the Makefiles should know to look there automatically. In the particular case of Gentoo's cpython, I have to admit I'm concerned that if I start mucking around with the Makefiles/autotool scaffolding, I'm going to break stuff. But maybe it's worth taking that risk if it allows us to do things more correctly going forward... I could at least take a crack at it and see what people think of the results. -gmt