Not entirely material, but I wrote this wrong:
libskarnet is in /usr//lib/x86_64-linux-gnu/ *
On Sun, Aug 9, 2015 at 2:33 PM, Buck Evan <buck_at_yelp.com> wrote:
> It's searching a set of "standard" paths (/lib/ and /usr/lib/) followed by
> the LIBDIR macro, which is hard coded to {prefix}/lib in their `
> build.sh.in`.
> The default prefix is /usr/local, so it's searching in /usr/local/lib.
> libskarnet is in /lib/x86_64-linux-gnu/ per Debian's multi-arch standard
> (I'm trying to make a Debian package).
>
> I don't see that there's any way to sufficiently alter the LIBDIR macro
> via configure options to get the necessary behavior.
> I believe I'll have to write a patch for make that is also part of my
> build process =(
>
> ---
> After quite a bit of staring at the debian packaging for make4.0, I've
> found they've done exactly that.
> i'll have to make this patch part of my build I suppose.
>
>
> https://sources.debian.net/src/make-dfsg/4.0-8.1/debian/patches/0001-debcherry-fixup-patch.patch/
>
> On Fri, Aug 7, 2015 at 5:34 PM, Laurent Bercot <
> ska-supervision_at_skarnet.org> wrote:
>
>> On 08/08/2015 01:29, Buck Evan wrote:
>>
>>> Laurent, I've just run across a counter example: (this gives me a
>>> bonafide
>>> issue when handling your -lskarnet rules)
>>>
>>> s6-user_at_696f14e9c9bd:~/scratch$ cat Makefile
>>> all: -lc
>>> echo $^
>>>
>>> s6-user_at_696f14e9c9bd:~/scratch$ make
>>> echo /usr/lib/x86_64-linux-gnu/libc.so
>>> /usr/lib/x86_64-linux-gnu/libc.so
>>>
>>> s6-user_at_696f14e9c9bd:~/scratch$ make --version
>>> GNU Make 3.81
>>>
>>> s6-user_at_696f14e9c9bd:~/scratch$ /opt/make/make
>>> make: *** No rule to make target '-lc', needed by 'all'. Stop.
>>>
>>> s6-user_at_696f14e9c9bd:~/scratch$ /opt/make/make --version
>>> GNU Make 4.1
>>> Built for x86_64-unknown-linux-gnu
>>>
>>
>> Interesting. It clearly shouldn't do that, because make-4.1 is
>> very much supposed to handle -l targets: if it didn't, no
>> skarnet.org package could ever build. I suspect it's related to
>> the way you installed it, something about vpaths and dynamic
>> linkers - but I'm too sleepy right now to investigate. If by
>> tomorrow you haven't found why it's not working, I'll give it a
>> try.
>>
>> --
>> Laurent
>>
>>
>
Received on Sun Aug 09 2015 - 21:35:01 UTC