betoh64

betoh64

[Thomas Klausner]

Hi!

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.

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?

Cheers,
 Thomas
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: betoh64

[Ingo Schwarze]

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

Re: betoh64

[Thomas Klausner]

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