From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id r4JNupAi027780 for ; Sun, 19 May 2013 19:56:52 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1UeDT7-00071X-FX; Mon, 20 May 2013 01:56:49 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1UeDT7-0004Yw-En for discuss@mdocml.bsd.lv; Mon, 20 May 2013 01:56:49 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1UeDT7-0007Nn-Du for discuss@mdocml.bsd.lv; Mon, 20 May 2013 01:56:49 +0200 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1UeDT7-0006fA-6J for discuss@mdocml.bsd.lv; Mon, 20 May 2013 01:56:49 +0200 Date: Mon, 20 May 2013 01:56:49 +0200 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: Re: betoh64 Message-ID: <20130519235648.GB5626@iris.usta.de> References: <20130307192824.GT26635@danbala.tuwien.ac.at> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130307192824.GT26635@danbala.tuwien.ac.at> User-Agent: Mutt/1.5.21 (2010-09-15) 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