Re: betoh64

[Ingo Schwarze <schwarze@usta.de>]

Hi Thomas,

Thomas Klausner wrote on Thu, Mar 07, 2013 at 08:28:24PM +0100:

> The latest release, 1.12.1, from last March doesn't build on NetBSD
> because of
> apropos_db.c: In function ???btree_read???:
> apropos_db.c:181:2: warning: implicit declaration of function ???betoh64???
> ...
> cc  -o apropos apropos.o apropos_db.o manpath.o libmandoc.a 
> apropos_db.o: In function `btree_read':
> /tmp/mdocml-1.12.1/apropos_db.c:181: undefined reference to `betoh64'
> /tmp/mdocml-1.12.1/apropos_db.c:182: undefined reference to `betoh64'
> *** Error code 1
> 
> config.h just has
> #if defined(__APPLE__)
> # define htobe32(x) OSSwapHostToBigInt32(x)
> # define betoh32(x) OSSwapBigToHostInt32(x)
> # define htobe64(x) OSSwapHostToBigInt64(x)
> # define betoh64(x) OSSwapBigToHostInt64(x)
> #elif defined(__linux__)
> # define betoh32(x) be32toh(x)
> # define betoh64(x) be64toh(x)
> #endif
> 
> and the Makefile assumes this macro must exist.

That alone ought to be easy enough to fix.
NetBSD certainly has some macros and functions
to convert between network and host ordering
and these just need to be plugged in.

> I saw on cvsweb that the current source does not contain the file
> apropos_db.c any longer.
> 
> Does anyone have a patch for 1.12.1?
> 
> Or is it perhaps time for an 1.13 release?

Oh what a mess, here is the much bigger problem.

In June 2012, Kristaps ripped out the db(3) backend of the apropos
database, plugged in an sqlite3(1) backend, then vanished (real
life is sometimes inconvenient).  I had a brief look at it, didn't
find the time to properly integrate it into OpenBSD, then real life
distracted me as well.  So now we have a bsd.lv HEAD that's basically
untested, out of sync from OpenBSD, and not suited to make a release.

The perfect solution would be to first properly integrate
the sqlite3(1) stuff into OpenBSD, make sure it works well
in practice, let the dust settle and then make a release using
the sqlite3(1) backend.  But i don't think i will come round to
that soon, it's too big a project for my spare time.

The main files affected are:
 - apropos.c
 - apropos_db.c
 - apropos_db.h
 - mandocdb.c
 - mandocdb.h
 - manpage.c
 - manpath.c
 - mansearch.c
 - mansearch.h
 - read.c

What else can we do?

 * Revert the sqlite3(1) stuff and move it to an experimental branch,
   that way resynching to OpenBSD such that we can make a release
   containing well-tested code?

 * Leave the sqlite3(1) stuff in as it is, hope that nobody
   really relies on mandocdb(8) yet, make sure everything
   except mandocdb(8) is well in sync with OpenBSD, and just
   make a release anyway?

Given that NetBSD has mdocml in ports and not in base, a release
is needed, directly synching with OpenBSD does not look viable.
Relying on proper upstream releases is not even a bad idea when
porting software.  (For OpenBSD, the situation is somewhat
different because i do much of mandoc development in the OpenBSD
tree, so it's not a port here but part of the base system.
But that's not the case for NetBSD or FreeBSD.)

Just telling people to continue working with 1.12.1 is not an
option either.  That's now more than a year old, lacking lots of
bug fixes and -Tman is frankly unusable in that version.
For a working -Tman, you really need OpenBSD -current or
bsd.lv HEAD, so a release is definitely needed.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv