Re: Some doubts about execline and skalibs

From: Alex Raschi <raschi.alex_at_gmail.com>
Date: Sun, 27 Dec 2020 12:07:06 +0100

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
>
Received on Sun Dec 27 2020 - 11:07:06 UTC