On Sunday 22 April 2012 00:44:11 Steven J Long wrote: > 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.
.LIBPATTERNS only matters if you specify the -lfoo in the dependency, and then
link in via an automatic make variable.
e.g. this:
$ cat Makefile
all: test
test: -lm
$ echo 'main(){}' > test.c
$ make
cc test.c /usr/lib/libm.so -o test
so the easy answer is: don't add -lfoo flags as dependencies to make targets.
if you want to have something link in a library, do:
$ cat Makefile
all: test
test: LDLIBS += -lm
$ make
cc test.c -lm -o test
> 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.)
i've seen this usage in only one or two packages before. and when i notified
the respective upstream, they weren't really doing it on purpose, so a simple
patch (like i showed above) they were fine with merging.
-mike
signature.asc
Description: This is a digitally signed message part.
