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
