Re: Some doubts about execline and skalibs
Thanks to both of you for you answers!
On Thu, Dec 24, 2020 at 10:26:20PM +, 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
Re: Some doubts about execline and skalibs
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
Re: Some doubts about execline and skalibs
Answering the part that I know the answer to. On Thu, Dec 24, 2020 at 02:38:04PM +0100, Alex Raschi wrote: > > Finally is there a way to set limits like with ulimit but without using > sh? > The command you're looking for is s6-softlimit in the s6 package. While limit setting is something that execline itself could handle that is rarely something that is done in stand-alone scripts and s6 (or some other process supervisor) is generally a requirement for most places where rlimit setting would be useful. -- Colin Booth
Some doubts about execline and skalibs
Hi,
I created 2 openbsd ports for skalibs and execline and i'm going to
submit them as soon i tested them enough, i was wondering a few things:
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?
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.
While execline built without warnings skalibs printed some, i think you
might find them useful so i'll leave them here (openbsd uses clang):
src/libstddjb/bitarray_clearsetn.c:11:55: warning: operator '<<' has lower
precedence than '+'; '+' will be evaluated first [-Wshift-op-parentheses]
unsigned char mask = (1 << (a & 7)) - 1 ^ (1 << 1 + (b-1 & 7)) - 1 ;
~~ ~~^~~
src/libstddjb/bitarray_clearsetn.c:11:55: note: place parentheses around the
'+' expression to silence this warning
unsigned char mask = (1 << (a & 7)) - 1 ^ (1 << 1 + (b-1 & 7)) - 1 ;
^
()
1 warning generated.
src/libstddjb/child_spawn1_internal.c:35:23: warning: & has lower precedence
than !=; != will be evaluated first [-Wparentheses]
if (p[to & 1] != to & 1)
^
src/libstddjb/child_spawn1_internal.c:35:23: note: place parentheses around the
'!=' expression to silence this warning
if (p[to & 1] != to & 1)
^
( )
src/libstddjb/child_spawn1_internal.c:35:23: note: place parentheses around the
& expression to evaluate it first
if (p[to & 1] != to & 1)
^
( )
1 warning generated.
src/libstddjb/netstring_get.c:42:20: warning: incompatible pointer types
passing 'size_t *' (aka 'unsigned long *') to parameter of type 'uint64_t *'
(aka 'unsigned long long *') [-Wincompatible-pointer-types]
if (!n || n != size_scan(buf, )) return (errno = EPROTO, -1) ;
^~~~
src/include/skalibs/types.h:213:43: note: expanded from macro 'size_scan'
#define size_scan(s, u) size_scan_base(s, (u), 10)
^~~
src/include/skalibs/uint64.h:48:57: note: passing argument to parameter here
extern size_t uint64_scan_base (char const *, uint64_t *, uint8_t) ;
^
1 warning generated.
src/libstddjb/uint640_scan_base_max.c:9:1: warning: all paths through this
function will call itself [-Winfinite-recursion]
{
^
1 warning generated.
Finally is there a way to set limits like with ulimit but without using
sh?
Thanks you for your projects, execline is awesome!
Cheers, Alex
