On Mon, Jan 16, 2017 at 01:05:36PM -0600, Jordon wrote:
> What is the ???official" way to pledge(2) a portable program?
> Put #ifdef __OpenBSD__ around the pledge call?
> Make an #ifndef __OpenBSD__ block that defined the function to always return
> Something better?
pledge() itself serves as good annotation of the subsets of POSIX
used by a program, one option to avoid the #ifdef pollution is to
detect if it's available first, otherwise:
The advantage of doing it this way is that the mainline code is
unchanged and so does not add additional maintenance burden (ie merge
conflicts). It also provides a hook for alternative implementation
mechanisms although there are no drop-in replacements at the moment.
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
> The advantage of doing it this way is that the mainline code is
> unchanged and so does not add additional maintenance burden (ie merge
> conflicts). It also provides a hook for alternative implementation
> mechanisms although there are no drop-in replacements at the moment.
> Darren Tucker (dtucker at zip.com.au)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
Thank you all for the replies. I like this approach. I guess it means I will
finally have to learn how that pre-build config thing works! :)
Dumb questions: what is that configure.ac file? Is that GNU autoconf or some
other config tool? Was it written by hand or generated? I need to learn
about the config process and I’m not sure where to start. I think some of
these build tools have GNU versions and BSD versions (like make). What is the
BSD standard for config scripts?
*sigh* this is a part of the build process that I have just put off for far
Jordon wrote on Fri, Jan 20, 2017 at 11:01:25PM -0600:
> I need to learn about the config process
> and I'm not sure where to start.
If you want to learn about automatic build configuration,
i'd recommend to *NOT* look at the GNU autotools - and at none
of the other monster systems like cmake, imake etc. either.
Because there, you spend huge amounts of time learning about the
ridiculous overengineering of these tools, and you will likely
not get a reasonable big picture of what the essential tasks
> What is the BSD standard for config scripts?
I'm not aware of any. Maybe having one might be nice - but the
need is not very pressing because it's quite simple to write
working autoconfiguration completely from scratch without any
That's an about 30.000 lines codebase of ISO C, but using some
BSD-specific extensions - err(3), fts(3) - and even OpenBSD-specific
extensions - ohash_init(3), reallocarray(3), strlcat(3), strlcpy(3),
strtonum(3) - along with a number of POSIX functions that some older
The configure-script is 474 lines of hand-written POSIX sh(1) code,
human-readable. It comes with 28 short test*.c files written in
human-readable C and with 17 compat_*.c files that are used to plug
in replacement implementations for functions missing in the system
we want to run on. Regarding how to use it, see the INSTALL file,
but basically, it boils down to the usual
./configure && make && make install
It works on any reasonable system (i didn't test it on systems
that were already obsolete 20 years ago, but is that relevant?)
In particular, it is tested on
- FreeBSD 9, 10, 11
- DragonFly BSD
- Minix 3
- Alpine, Arch, Slackware, Crux Linux
- Void Linux with both glibc and musl
- debian GNU/Linux wheezy, jessie, stretch, sid
- CentOS 5 & 6, Fedora 20, RHEL 5 & 6
- SLES 11, openSUSE 13, xUbuntu 12 & 14
- MacOS X Tiger and El Capitan
- IBM AIX 7.1
- Oracle Solaris 11
- SUN OS 5.9 and 5.10
Do you want to support more? Like, what about 4.3BSD-Reno?
Or maybe DEC ULTRIX? Not really, right?