| 1 |
Hi, |
| 2 |
|
| 3 |
I've been working with GNU make quite a lot recently, and I came across the |
| 4 |
.LIBPATTERNS variable. This variable means that make expands all -lname |
| 5 |
prerequisites via a library path search of /lib and /usr/lib *before* any |
| 6 |
command sees it. (It searches local paths set in the makefile first, which |
| 7 |
is useful for linking to built libs, though imo the build-system is better |
| 8 |
off using -L parameters in LDFLAGS for those.) |
| 9 |
|
| 10 |
You can read about it in 'info make' Section 4.5.6 (just hit / and type |
| 11 |
LIBPATTERN<Enter> to find it.) |
| 12 |
|
| 13 |
The default setting is active in make as installed, as it should be, which |
| 14 |
you can verify with: make -p -f /dev/null|grep -F LIBPATTERN |
| 15 |
|
| 16 |
I can find nothing overriding it in portage, which makes sense, since in |
| 17 |
general one cannot know if the package in question uses gmake .LIBPATTERNS |
| 18 |
to link to locally-built libs. However I can't help thinking of it as |
| 19 |
harmful for a package manager, since a command like ld would be given a |
| 20 |
parameter of say, /usr/lib/libfoo.so, not -lfoo, meaning LDFLAGS would be |
| 21 |
irrelevant for its lookup. |
| 22 |
|
| 23 |
My feeling is that build-systems reliant on the default gmake behaviour for |
| 24 |
locally-built libs (ie not setting any -L params and also having to link |
| 25 |
locally) would be rare, but it's just that: a gut-feeling with no data. |
| 26 |
Preferably they'd be marked as such so that the package manager could deal |
| 27 |
with that corner-case, while patches to supply local -L params could be |
| 28 |
worked on, in advance of submission upstream. |
| 29 |
|
| 30 |
I'd hope upstream would accept them, since it makes cross-development |
| 31 |
easier. (One definitely does not want make expanding -lname to a library in |
| 32 |
/lib or /usr/lib in that case, and it's better to error out if the library |
| 33 |
can't be found than link to host libs.) |
| 34 |
|
| 35 |
The reason I bring it up is because we have been discussing library linkage |
| 36 |
issues wrt initramfs. I also seem to recall quite a few blog posts and |
| 37 |
discussions of arbitrary linkage to libs in /usr. .LIBPATTERNS not being |
| 38 |
empty would certainly explain that. |
| 39 |
|
| 40 |
Regards, |
| 41 |
Steve. |
| 42 |
-- |
| 43 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives