Hi Alex,
I noticed that both skalibs and execline have -fno-stack-protector by default, i haven't found anything related while searching commits or mailing lists. Is this flag a left over or it's wanted?
It's a nice default for code size and efficiency, when you're confident enough in your programming practices to assert you're not going to smash the stack. Call it hubris. :) (I have spat in the wind a lot of times, and regretted it more often than not, but I'm proud to say that this particular sputum has never hit me in the face. Yet.) It's like this because originally the skarnet.org project was made to run on small devices where that kind of optimization does count. I suspect nowadays it makes a lot less difference than it did a decade ago - so maybe I should just remove it and leave it to the toolchain's default. It's policy, after all. Anyway, it's overridable: any option you pass in CFLAGS will take precedence over the default flags. If the OpenBSD policy is to build everything with -fstack-protector, then it shouldn't be a problem to have it in CFLAGS.
Another thing i was wondering is why both packages put the shared library under lib/ but the static one under lib/skalibs/ and lib/execline/. If i leave libskarnet.a under lib/skalibs/, building execline statically fails because it does not find libskarnet.a.
I probably have already ranted about this zillions of times, but I cannot find a stable reference in the ML archives, so it must have been on #s6. Anyway, here goes: I have a pet peeve (actually, one of many): FHS and build tools like to treat shared libraries and static libraries the same way, when in reality they are *not the same kind of object at all*. Static libraries are build-time objects, used in development only; shared libraries are run-time objects that are also used at build time because reasons. To me, it's a complete misdesign that /usr/lib is used to store both static and shared libraries. I have a lot - *a lot* - of criticism to wield against FHS, but this one might lowkey take the cake. (Okay, no: the worst is that the FHS structure makes atomic package upgrades impossible. But /usr/lib is definitely top 4.) And so, since ld.so uses /usr/lib:/lib as its default path for shared libraries, I treat /usr/lib as a place to store shared libraries, i.e. run-time objects, and would rather store additional build-time objects somewhere else. And /usr/lib/$package didn't sound like a terrible option, since it's already an existing convention to store other read-only package-specific files such as libexec or data files. I agree that this is non-standard, and like every. single. fcking. time. I have deviated ever so slightly from the well-trodden path, despite extensively describing things in the INSTALL file, people bump against the obstacle. So much that it's probably not worth doing it in the first place, despite being cleaner in theory. You can probably expect the default for static libraries to change to /usr/lib at some point in the future, but I'm not completely ready to surrender that small hill yet. For now, if your configure script invocation does not change the defaults at all, it will automatically fill in the vpaths and linker invocations with the appropriate -L options, so things will work out of the box. But as soon as you deviate from the default, the configure scripts assume that you know what you are doing and have read the INSTALL file, and they stop holding your hand - so you need to use the appropriate --with-lib options in order to find all the static libraries a package needs. Alternatively, you can use --libdir=/usr/lib for all the skarnet.org packages, and it will nicely install everything into /usr/lib so things will work too.
While execline built without warnings skalibs printed some, i think you might find them useful so i'll leave them here (openbsd uses clang):
Thanks. The extra parentheses have already been added in git. There is a new set of numbered releases planned for Very Soon (tm), likely very early next year; this will be a major skalibs release, which a few compatibility breaks, and every package is being updated for it, so you may want to wait for it before submitting your ports. :)
src/libstddjb/child_spawn1_internal.c:35:23: warning: & has lower precedence than !=; != will be evaluated first [-Wparentheses] if (p[to & 1] != to & 1)
I actually saw this one while reading the clang build logs a few months ago and realized it was a bug, so despite not being a fan of adding parentheses where they're not needed in order to silence the warnings, I have to admit that for once -Wparentheses was useful. :D (Fortunately, in practice 'to' is always 0 or 1, so the bug never manifested.)
Finally is there a way to set limits like with ulimit but without using sh?
Colin answered that one: s6-softlimit, in the s6 package. At some point the border between execline and s6 becomes fuzzy: there is an "s6-envdir" tool in s6, but an "envfile" tool in execline, that are very similar and should really be found in the same package. It would be a reasonable take to say that generic utilities should be in execline, and that s6 should only host tools that are somehow related to supervision or running services. I might migrate some tools in the future, but it's always difficult for key packages like these ones, especially since it's now possible (at the request of grumpy, unpleasant, ugly people) to build s6 *without* execline. Sometimes the best way to handle a mediocre situation is to not make it worse. So I really don't know.
Thanks you for your projects, execline is awesome!
Thanks! The next release will streamline a lot of scripting with forstdin and other tools that read lines. I hope you'll find it useful. -- Laurent
