On 12/01/2015 22:27, Olivier Brunel wrote:
> 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)
Then how do you explain that it works in the non-parallel case ? The
sequence of actions you described applies too.
> 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.
Good idea, I'll do that.
> 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?
Yes, exactly.
You shouldn't use buffer_0f1 unless you're writing a blocking filter.
buffer_0f1 is just like buffer_0 except that it flushes buffer_1 right
before attempting to read on stdin - which means that everytime your
program risks blocking, it makes sure stdout is flushed first. It's
optimal buffering behaviour for a filter (way better than the standard
line buffering / full buffering distinction), but it's hackish, so
make sure you do not use it outside of this very specific case.
> And, so long as I don't mix e.g. buffer_1 with buffer_1small, I can use
> them in my code safely?
Yes. Just don't mix small with non-small and you'll be fine. :)
--
Laurent
Received on Mon Jan 12 2015 - 23:51:59 UTC