From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from danbala.ifoer.tuwien.ac.at (danbala.ifoer.tuwien.ac.at [128.130.168.64]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id r4K9qBQ9016408 for ; Mon, 20 May 2013 05:52:12 -0400 (EDT) Received: by danbala.ifoer.tuwien.ac.at (Postfix, from userid 116) id 4A487390357; Mon, 20 May 2013 11:52:10 +0200 (CEST) Date: Mon, 20 May 2013 11:52:10 +0200 From: Thomas Klausner To: discuss@mdocml.bsd.lv Subject: Re: betoh64 Message-ID: <20130520095210.GB20057@danbala.tuwien.ac.at> References: <20130307192824.GT26635@danbala.tuwien.ac.at> <20130519235648.GB5626@iris.usta.de> 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: <20130519235648.GB5626@iris.usta.de> Hi Ingo! On Mon, May 20, 2013 at 01:56:49AM +0200, Ingo Schwarze wrote: > Thomas Klausner wrote on Thu, Mar 07, 2013 at 08:28:24PM +0100: > > 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 found, in sys/endian.h: #define be16toh(x) htobe16(x) #define be32toh(x) htobe32(x) #define be64toh(x) htobe64(x) #define le16toh(x) htole16(x) #define le32toh(x) htole32(x) #define le64toh(x) htole64(x) so perhaps it's just a missing header after all. > 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? NetBSD's not using mdocml's apropos, but its own, so from my POV, even the last option is fine. > Given that NetBSD has mdocml in ports and not in base That's not correct, NetBSD has mdocml in base even in NetBSD-6. But we don't develop that version, we just import releases. > 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. I'd definitely like to have a version with working -Tman... so I'd say go for the version that can be achieved more quickly. :) Thomas -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv