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