Thanks to both of you for you answers! On Thu, Dec 24, 2020 at 10:26:20PM +0000, Laurent Bercot wrote: > > 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.
I hadn't thought about small devices and yes this one is not a problem but in my case i do: sed -i /-fno-stack-protector/d ${WRKSRC}/configure because the ports system does not pass any flags about stack protector and/or retguard, they are enabled by default. > > 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. My fault for not reading INSTALL carefully enough, this is a lesson for the next times. Thanks for clarifying this again. > > 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. :) I wait for them! > > 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. Yeah i have used s6-envdir a little before envfile was updated to allow more complex variable values and i wondered why they were in different packages. > > > > 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 >