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
Received on Thu Dec 24 2020 - 22:26:20 UTC