| 1 |
On Sunday 22 April 2012 00:44:11 Steven J Long wrote: |
| 2 |
> I can find nothing overriding it in portage, which makes sense, since in |
| 3 |
> general one cannot know if the package in question uses gmake .LIBPATTERNS |
| 4 |
> to link to locally-built libs. However I can't help thinking of it as |
| 5 |
> harmful for a package manager, since a command like ld would be given a |
| 6 |
> parameter of say, /usr/lib/libfoo.so, not -lfoo, meaning LDFLAGS would be |
| 7 |
> irrelevant for its lookup. |
| 8 |
|
| 9 |
.LIBPATTERNS only matters if you specify the -lfoo in the dependency, and then |
| 10 |
link in via an automatic make variable. |
| 11 |
|
| 12 |
e.g. this: |
| 13 |
$ cat Makefile |
| 14 |
all: test |
| 15 |
test: -lm |
| 16 |
$ echo 'main(){}' > test.c |
| 17 |
$ make |
| 18 |
cc test.c /usr/lib/libm.so -o test |
| 19 |
|
| 20 |
so the easy answer is: don't add -lfoo flags as dependencies to make targets. |
| 21 |
if you want to have something link in a library, do: |
| 22 |
$ cat Makefile |
| 23 |
all: test |
| 24 |
test: LDLIBS += -lm |
| 25 |
$ make |
| 26 |
cc test.c -lm -o test |
| 27 |
|
| 28 |
> I'd hope upstream would accept them, since it makes cross-development |
| 29 |
> easier. (One definitely does not want make expanding -lname to a library in |
| 30 |
> /lib or /usr/lib in that case, and it's better to error out if the library |
| 31 |
> can't be found than link to host libs.) |
| 32 |
|
| 33 |
i've seen this usage in only one or two packages before. and when i notified |
| 34 |
the respective upstream, they weren't really doing it on purpose, so a simple |
| 35 |
patch (like i showed above) they were fine with merging. |
| 36 |
-mike |
Archives