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 1SLocF-0005HU-Iv for garchives@archives.gentoo.org; Sun, 22 Apr 2012 04:41:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05860E0B12; Sun, 22 Apr 2012 04:41:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3B8AFE0A88 for ; Sun, 22 Apr 2012 04:40:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 7B5881B40EA for ; Sun, 22 Apr 2012 04:40:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5.5 tests=[AWL=-1.028, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4bzLleVMM1I for ; Sun, 22 Apr 2012 04:40:29 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id D3ED41B4010 for ; Sun, 22 Apr 2012 04:40:28 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SLoaz-00007X-RL for gentoo-dev@gentoo.org; Sun, 22 Apr 2012 06:40:21 +0200 Received: from 109.176.242.43 ([109.176.242.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 06:40:21 +0200 Received: from slong by 109.176.242.43 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 06:40:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] .LIBPATTERNS harmful? Date: Sun, 22 Apr 2012 05:44:11 +0100 Organization: Friendly-Coders Message-ID: 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: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.242.43 X-Archives-Salt: 16779c7a-9658-477f-948a-a45eb45a716f X-Archives-Hash: ad7472d1e0f5f066c33c56a9c7cdac4e Hi, I've been working with GNU make quite a lot recently, and I came across the .LIBPATTERNS variable. This variable means that make expands all -lname prerequisites via a library path search of /lib and /usr/lib *before* any command sees it. (It searches local paths set in the makefile first, which is useful for linking to built libs, though imo the build-system is better off using -L parameters in LDFLAGS for those.) You can read about it in 'info make' Section 4.5.6 (just hit / and type LIBPATTERN to find it.) The default setting is active in make as installed, as it should be, which you can verify with: make -p -f /dev/null|grep -F LIBPATTERN I can find nothing overriding it in portage, which makes sense, since in general one cannot know if the package in question uses gmake .LIBPATTERNS to link to locally-built libs. However I can't help thinking of it as harmful for a package manager, since a command like ld would be given a parameter of say, /usr/lib/libfoo.so, not -lfoo, meaning LDFLAGS would be irrelevant for its lookup. My feeling is that build-systems reliant on the default gmake behaviour for locally-built libs (ie not setting any -L params and also having to link locally) would be rare, but it's just that: a gut-feeling with no data. Preferably they'd be marked as such so that the package manager could deal with that corner-case, while patches to supply local -L params could be worked on, in advance of submission upstream. I'd hope upstream would accept them, since it makes cross-development easier. (One definitely does not want make expanding -lname to a library in /lib or /usr/lib in that case, and it's better to error out if the library can't be found than link to host libs.) The reason I bring it up is because we have been discussing library linkage issues wrt initramfs. I also seem to recall quite a few blog posts and discussions of arbitrary linkage to libs in /usr. .LIBPATTERNS not being empty would certainly explain that. Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)