Re: building (with) execline

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Mon, 12 Jan 2015 22:27:34 +0100

On 01/12/15 21:27, Laurent Bercot wrote:
> On 12/01/2015 18:30, Olivier Brunel wrote:
>
> Hi Olivier,
>
>> I usually build things with -j4, but with e.g. execline I get an error:
>>
>> make: *** No rule to make target '-lexecline', needed by 'background'.
>> Stop.
>> make: *** Waiting for unfinished jobs....
>
> Yeah, that's a known problem, and I think the issue is with make.
>
>
>> In that case, I think you need to use e.g. libexecline.a instead, so
>> that make can order things properly even with parallel jobs.
>> I tried replacing -lexecline with $(STATIC_LIBS) in deps.mak and I can
>> `make -j4` just fine. Of course this won't work when building with
>> --disable-allstatic, where other changes might be in order.
>
> That's the very point: I need a solution that works with both
> libexecline.a and libexecline.so. If it was only me, I'd use
> libexecline.a everywhere, but you know how distributions love
> dynamic linking, so I want to make it easily accessible.
>
> GNU make is supposed to replace -lexecline with the static or the
> dynamic version depending on what it finds first, and my Makefile has
> vpath instructions at the beginning, so it's definitely supposed to
> work - but apparently, vpath search doesn't mesh well with make -j,
> and this is not documented in the GNU make manual.

I may be wrong, but the way I read the info page about this (4.5.6
Directory Search for Link Libraries) I took it that this special
handling of processing -lFOO and looking in directories for e.g.
libFOO.so then libFOO.a (by default) was only done as such, i.e. to
search for the prerequisite (and see if a rebuild is needed if more
recent), but when that search fails to find something, then it fails.

Because make doesn't know which would be found/used, it has no recipe to
build it (e.g. how would it know whether to build libFOO.so or
libFOO.a?), as indicated by the error (no rule to make -lexecline)

That's why it works fine for "external" libraries, e.g. -lskarnet, but
not when the library is part of the build process. At least that's how I
read it, hence why I said in this specific case you'd need to use the
actual filename, so there's a rule to make it and make knows to then
wait for it (in case of parallel jobs).
Of course I may be wrong, and this may be an actual bug in make.

> I will try to come up with a workaround.

If you don't have one by the time of next release, may I suggest simply
adding a target .NOTPARALLEL so that the -j flag is basically ignored.
Doesn't really solve anything, but at least it will always build.


(...)


>> Also, I've made a little thing that works say somewhat like execline's
>> define, and tried to compile it, but it fails. I get a few errors such
>> as:
>> /usr/lib/execline/libexecline.a(el_transform.o): In function
>> `el_transform':
>> (.text+0x112): undefined reference to `satmp'
>> (...)
>> % gcc test.c -static -Wall -lskarnet -lexecline -L/usr/lib/skalibs
>> -L/usr/lib/execline
>
> That's a classic linker trap. You need to put the lower-level libraries
> *after* the higher-level libraries on gcc's invocation command line.
> Try "-lexecline -lskarnet" instead of "-lskarnet -lexecline". That
> should solve all your symbol-related problems.

Ah! Thanks a lot, that was my mistake indeed.

>
>
>> Yeah, back to stralloc, in your code (e.g. s6) you seem to use it
>> (satmp) at times, but I have no idea how this works. Obviously, it's
>> also something libraries (at least libexecline) might use, so is it
>> meant for app or to be an internal thing that you abuse in your own
>> code? How safe is it to use if library functions can use it?
>
> satmp is a global stralloc. The point of satmp is to have a unique
> place for temporary allocations that have to use the heap for some
> reason, instead of making strallocs all over the place and freeing
> them. Reusing the same storage space (and freeing it at the end)
> is cheaper than having series of malloc/free, and it makes it easier
> to keep track of your heap.
>
> You can use it safely provided you're using it as a stack:
> * unsigned int oldlen = satmp.len
> * stralloc_catb whatever you want to satmp, whatever is above
> oldlen is free for you to use. What is below oldlen, however,
> is data needed by your caller, and you can't touch it.
> * satmp.len = oldlen
> Always restore satmp.len when you exit your function, even in
> error conditions.
>
> But then again, globals are ugly, so it's probably more trouble
> than it's worth. It's certainly easier and safer for you to make your
> own private stralloc instead of bothering with satmp for some micro
> optimization.
>

I see, good to know. So I'll do some reading re: buffered IO, but just
to make sure: the buffer_0, buffer_0f1, buffer_1, etc are ways to use
stdin, stdout and stderr directly with "pre-allocated" buffers, right?

And, so long as I don't mix e.g. buffer_1 with buffer_1small, I can use
them in my code safely?



Thanks again,
-j
Received on Mon Jan 12 2015 - 21:27:34 UTC