OpenBSD Journal

Developer Blog - deanna@: porting non-portable code

Contributed by deanna on from the S&M dept.

Though I've been using OpenBSD since 2.4, I only started making ports about 6 months ago. So, if the opinions here seem newbish, it's because I haven't yet resigned myself to the fact that non-OpenBSD code just s^H well ... is a bit different. :-)

I've been working on a particular set of ports, off and on, for a few months now. The reason why it's off and on is that the quality of the free software for this particular task is sometimes demotivating. Such a claim is useless without examples, right?

Here's one: the distfile hasn't changed in two years, and is also one of the top search results for free software in this area. Must be a stable release, right? Not quite. Besides the usual differences (I showed a friend a block of the code and he squealed, closed his eyes and told me to make it go away), one of the source files is actually missing a semicolon. How do you let your project sit around for two years with a missing semicolon? Who knows, maybe it is intentionally left broken to keep the kiddies from abusing it. ;-)

Another... the distribution is about 50% emacs backup~ and #swap# files.

And another... the latest version was announced in early November, but the distribution is a zero-byte file.

But the last one is what really got me thinking: glibc functions _GNU_SOURCE #defines all over the place. Why would anyone release free software that is so non-portable? And this isn't systems programming, it's just a not-very-exciting everyday app. I don't get it. The Linux man pages are actually nice enough to tell you when something isn't portable; and you don't see fmt_scaled(3) all over pf and OpenBGPD.

Now, to be fair. I've recently started a new job where my desktop machine runs Solaris, and there's nothing I can do about that. Naturally, the first thing I had to do was port mg(1), since I can't live without it. Surprise, the amount of [Open]BSDisms in that program probably equals or exceeds the Linuxisms in the program I just mentioned. But, mg is an OpenBSD base system utility, so the comparison isn't really valid. What's more, OpenSSH's compatibility library makes porting this much easier. And, unlike Linux, Solaris has safe string functions.

I'm not quite finished with mg for Solaris -- at this point when I try to open a file, I end up in dired. But I'm in no hurry, since this gives me something fun to do when I need the hacking equivalent of a bubble bath. :-)

I don't really mean to condemn anyone here. I have no right to complain about what's given freely, and if porting were simple and mindless, it wouldn't be any fun. The time I spent working on Gnash made it very clear to me how hard it is to write portable code -- it seemed like those guys committed as many autoconf macros as they did actual program source. The resulting configure script was 1.5MB (!) and it runs on everything from IRIX to RISC OS to Haiku. But that's way above and beyond what we need to make a decent port. The challenge isn't people who don't write for OpenBSD, it's the ones who go to the other extreme by writing OS-specific code which locks us out.

(Comments are closed)

Comments

  1. By Jasper Lievisse Adriaanse (jasper) jasper@openbsd.org on http://humppa.nl

    The challenge isn't people who don't write for OpenBSD, it's the ones who go to the other extreme by writing OS-specific code which locks us out.
    Couldn't have said it better!

    Comments

    1. By mpa (83.17.211.222) on

      > The challenge isn't people who don't write for OpenBSD, it's the ones who go to the other extreme by writing OS-specific code which locks us out.
      > Couldn't have said it better!

      On the other hand author states:

      "Naturally, the first thing I had to do was port mg(1), since I can't live without it. Surprise, the amount of [Open]BSDisms in that program probably equals or exceeds the Linuxisms in the program I just mentioned."

      Writing really portable code (think plan9 -- no ifdefs) isn't possible
      on unix. Really, look at openbsd-compat -- really simple functions
      need to implemented differently on different flavours of "unix".
      POSIX isn't simply enough.


      Comments

      1. By Anonymous Coward (24.46.21.229) on

        SNIP
        > Writing really portable code (think plan9 -- no ifdefs) isn't possible
        SNIP

        That's true for *c on Plan9 (8c, vc, &c), but pcc (from APE) works fine with ifdefs, since it uses cpp to preprocess much like the rest of the C universe it seems. So it's not really as bad as you may think (although APE does need some spring cleaning).
        On a side note, things like Python work well (albeit with a patch), even with 8c, so some people are doing the right thing (TM).

  2. By Buck (207.59.73.8) on

    > And, unlike Linux, Solaris has safe string functions.

    Linux does, too

    $ grep -w strlc.. /boot/System.map-`uname -r`
    c01b97c2 T strlcat
    c01b9832 T strlcpy

    now, glibc, o/t/o/h, . . .

  3. By Anonymous Coward (71.216.4.2) on

    > Naturally, the first thing I had to do was port mg(1), since
    > I can't live without it.

    i've never tried it on Solaris, but have you looked at this?
    http://www.xs4all.nl/~hanb/software/mg/

    Comments

    1. By Igor Sobrado (sobrado) igor@string1.ciencias.uniovi.es on

      > > Naturally, the first thing I had to do was port mg(1), since
      > > I can't live without it.
      >
      > i've never tried it on Solaris, but have you looked at this?
      > http://www.xs4all.nl/~hanb/software/mg/

      I have tried release 20061224 right now. It does not build with Sun Studio (Sun C 5.8 2005/10/13) at home... well, on the Department of Geological Sciences we have a Blade 2000 that has gcc and gmake installed on it:

      $ ./configure
      -n Looking for internal arc4random...
      Not Found.
      -n Looking for external arc4random...
      Not Found.
      -n Looking for strtonum...
      Not Found, adding.
      -n Looking for strlcpy...
      Found.
      -n Looking for strlcat...
      Found.
      -n Looking for fgetln...
      Not Found, adding.
      -n Testing for strict aliasing...
      Fails.
      -n Looking for glibc...
      Not on this system
      -n Looking for version...
      Other ls
      OK, now run `make'.
      $ gmake
      gcc -O2 -pipe -g -Wall -Werror -c autoexec.c
      In file included from autoexec.c:5:
      def.h:24: stdint.h: No such file or directory
      gmake: *** [autoexec.o] Error 1

      Funny... by the way, same problem with release 20061222. :-(

      Igor.

      Comments

      1. By Deanna Phillips (deanna) on 

        > $ gmake
> gcc -O2 -pipe -g -Wall -Werror  -c autoexec.c
> In file included from autoexec.c:5:
> def.h:24: stdint.h: No such file or directory
> gmake: *** [autoexec.o] Error 1

        Yes, that is just a Linux port.

        The Solaris part isn't really difficult, it's just reading man pages and grepping around for the right header files. But I was saving it for when I felt homesick. :-)

        I'll send it to Han when it's finished.

  4. By Igor Sobrado (sobrado) igor@string1.ciencias.uniovi.es on

    In my humble opinion, well written software does not require autoconf-like tools. I never trusted on software developed using these tools. Ok, in the past (up to mid-90s) changes to Makefiles were sometimes required, but when software is carefully written these changes are usually a few and well documented ones. It is so easy compiling well written software...

    I think that software quality follows a negative slope in the last decade.

    Cheers,
    Igor.

    Comments

    1. By Anonymous Coward (74.115.21.120) on

      > In my humble opinion, well written software does not require autoconf-like tools. I never trusted on software developed using these tools. Ok, in the past (up to mid-90s) changes to Makefiles were sometimes required, but when software is carefully written these changes are usually a few and well documented ones. It is so easy compiling well written software...

      In my humble opinion, you have never written any significant code. Go ahead and write something like perl or python, and have it run on all unixes without a configure script.

  5. By junkie (unixjunkie) unxfan@dontspam.org on http://www.unixgarage.com

    Finally! I thought I was the only one.

    Although I don't particularly work on alot of porting projects, I do like to use open source software when it makes sense. The number of times I downloaded tarballs and attempted to build them just to run into all kinds of troubles makes me very hesitant to try new things.I think making broad generalization is unfair, there are several open source projects that are very well managed. I think one way to make things easier is to look for the app on the repositories of stable OS's/distros. they may have some patches to make it really work. I agree with some of the posts here, I think m4,autoconf,automake add significant unnecessary complexity. in an ideal world, we should just type make and the thing should build. I think that the free/open source software community should start looking into establishing some guidelines and help docs around release engineering and even coding techniques. these are hard problems even in large well funded environments but it is not impossible and this very project, OpenBSD , proves it is a very attainable goal.
    just my 2 cents

  6. By Ben (mouring) mouring@nospam.eviladmin.org on http://eviladmin.org

    "What's more, OpenSSH's compatibility library makes porting this much easier. And, unlike Linux, Solaris has safe string functions."

    There is a reason why this is the case. The OpenSSH portable team (With a bit of nudging from Theo, IIRC) was looking for a way to attempt to reduce the impact portable code on the OpenSSH code. So the compat functionality went through at least two major changes under my hacking in an attempt to pull functions out and make it generic as possible, and try to keep platform specialized code out of the main OpenSSH code.

    As a result I know that Darren Tucker has used aspects of it to help bootstrap an universal OpenNTPd port. I believe others have used it to help do quick ports as well.

    As far as portability... There are a lot of times the OpenSSH developers and Theo discussed and changed what function calls we used in the OpenBSD tree to lessing the OpenSSH portability issues. We moved to more common function calls, etc. I'm sure if someone was serious about mg and understand what problems existed and what portable APIs would be more acceptable to OpenBSD team and other platforms it may be accepted upstream.

    Speaking of such things.. my god has no one killed off bsd-nextstep.[ch] yet?! Does that platform even work for OpenSSH.. Last I left it, there was a lot of niggly things that needed major help. =-)

    - Ben

  7. By cnst (cnst) on

    > I've recently started a new job where my desktop machine runs Solaris, and there's nothing I can do about that.

    Do you work at Sun now? :)

  8. By Chris Wareham (194.193.52.249) chriswareham@chriswareham.demon.co.uk on http://www.chriswareham.demon.co.uk/

    I've ported mg(1) to both Mac OS X and Linux (I use the former at home and the latter at work), as I don't need all the extra stuff in a full blown Emacs. I've put the code here in case anyone's interested - I updated it to match the CVS version from the OpenBSD sources today (3rd January).

    Chris

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]