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
