public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] .LIBPATTERNS harmful?
@ 2012-04-22  4:44 Steven J Long
  2012-04-22 15:17 ` Mike Frysinger
  0 siblings, 1 reply; 3+ messages in thread
From: Steven J Long @ 2012-04-22  4:44 UTC (permalink / raw
  To: gentoo-dev

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<Enter> 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 ;-)





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-04-22 22:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-22  4:44 [gentoo-dev] .LIBPATTERNS harmful? Steven J Long
2012-04-22 15:17 ` Mike Frysinger
2012-04-22 22:13   ` [gentoo-dev] " Steven J Long

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox