Re: Current status of OpenBSD BEAST

[Tim Janik <timj gtk org>]

On Sun, 28 Dec 2003, Nedko Arnaudov wrote:

> Tim Janik <timj@gtk.org> writes:
>
> > please figure what breaks upon building docs. i can't simply disable
> > doc generation in CVS if it's not working on your system.
> make in docs/generated says that it cannot find beast.1 (cannot make it)
> may be this is problem with my build environment.

can you post the exact errors you're getting?
maybe the beast makefile setup needs some fixing, or the doc
build tools, i.e. texitheque, and its maintainer, alper ersoy
is also on this list.

> However until I find
> exact problem I decided to skip this directory. The other argument is
> that 'make install'ed beast cannot run at this time anyway because it
> searches its dynamic libraries in paths relative to current directory
> (this is another thing that I need to solve).

how do other packages that come with libraries or link against
libraries deal with this on bsd?

> >> -#include	<sys/soundcard.h>
> >> +#include	<soundcard.h>
> >
> > this will break on linux. you actually want to add a check to configure.in
> > here, and then define something like SOUNDCARD_H which can be used for these
> > include statements (let it default to <sys/soundcard.h> if <soundcard.h>
> > wasn't found, so things still work on linux).
>
> Actually OSS audio is emulation layer in OpenBSD so I plan to use native
> audio (or if it is not good enough make/use other API to audio
> hardware). It is strange to me why Linux OSS API emulation is made in
> not compatible header path. May be some time ago linux header lived in
> /usr/include and was moved to /usr/include/sys later. Other possibility
> is that it is in /usr/include in some Linux distribution. I cannot make
> good enough check where soundcard.h lives until I find why it is where
> it is.

that might be interesting to find out, but for the short term, a simple
check on whether soundcard.h is in /usr/include or /usr/include/sys
should be sufficient for people to build beast on bsd.

> Also on other platforms soundcard.h may implement other audio API
> so checking for openbsd build host may be appropriate.

i've looked at quite a few audio drivers so far, and i've not found
an indication that that would be the case. unless you have a concrete
example to show soundcard.h being used for something else on some
platform, i tend to assume it covers the OSS API.

> But it is likely
> that check for BSD is the right thing because BSDs have many
> shared(actually synchronized between projects) code.

no, not a bsd check. simply a check on what the exact location
of the header file is.

> >> -  if (user && 1 /* getpwnam_r check */)
> >> +  if (user && 0 /* getpwnam_r check */)
> >
> > similar to soundcard.h, the patch here should check for getpwnam_r() in
> > configure.in, and special case based on that.
>
> I also think that this is good candidate for autoconf check. May be I'll
> do it if I find common build environment with linux developers. Until
> then OpenBSD developer must apply patches anyway.

i don't understand, what do you mean with "I find common build environment
with linux developers"?

> >> +#include <unistd.h>
> >
> > can you add what warning/error you get exactly without unistd.h?
> > e.g. something like: #include <unistd.h> /* for exit() */
>
> this is required for sleep()
> man 3 sleep for linux also says that unistd.h is required.
> How it compiles in your build environment is mystery for me. Calling
> functions without prototype ot definition is not allowed in C++ AFAIK.

stefan, any input on this? the file in question is tests/cxxbinding.cc.

> >> -AUTOCONF_VERSION=2.50
> >> +AUTOCONF_VERSION=2.58
> >
> > this affects a bunch of developers, i'd like to hear particular reasons
> > for upgrading the autoconf dependancy, i.e. did you make sure <2.58 breaks
> > for you, and if so, why?
>
> The reason is that 2.50 is not one of available OpenBSD ports.
> Available are 2.13 2.52 2.54 2.56 2.57
> Since you said that you use 2.58, I used it too.
> Also check for >= 2.50 is more appropriate as you said earlier.
> autgen.sh is too linux dependent (GNU grep) and not enough smart so may
> be more work needs to be done there.

oh, didn't know. grep -q is fixed in CVS now.

> One smart thing is to make better
> test for versions. Checking for presence of " 1.4\b" inis not very good
> test for 1.4 version. First it checks it within all output. Second
> . means any chat withing regexps.

erm, what check exactly do you suggest then?

> >> -#LIBTOOL=libtool
> >> +LIBTOOLIZE=libtoolize
> >> +LIBTOOLIZE_VERSION=1.5
> >
> > i don't quite see what the point here is, CVS already has
> > libtoolized files of version 1.5.
>
> point is that libtool version in CVS assumes that SED environment
> variable is set externaly which is not the case in my build
> environment. May be if I used autoconf version 2.50 it will set it.

i can't verify that libtool wants an externally set $SED,
in my build environment (beast/):

$ set | fgrep SED | wc -l
0
$ grep ^SED= *
aclocal.m4:SED=$lt_SED
aclocal.m4:SED=$lt_cv_path_SED
configure:SED=$lt_cv_path_SED
configure:SED=$lt_SED
libtool:SED="/bin/sed"

> > including these files in the diff really didn't help much.
> > if you meant to say that they should be removed from CVS,
> > a few words would have been more appropriate than sending
> > 300k of "- ..." lines.
>
> I sent patches that worked for me. The only way to remove files by
> running patch that I've found is the -N option to diff and this makes
> the files so large. Next time I'll send them compressed.

well, to remove the libtool files, i'd rather have have you send me:
  rm ltmain.sh
than a patch ;)
but what's more interesting is, does your 1.5 version behave
differently than the one in CVS?

> > in any case, i'd like to hear why you did those libtool changes,
> > does the CVS 1.5 version not work for you, and your 1.5 version
> > does?
> see above
> libtool in CVS does not work for me, mine does.

what's the exact difference/error yoU're getting then?

> Also using fixed libtool and not using fixed configure looks strange to
> me. If the reqson is to minimize build trouble, from my point of view it
> has opposite effect.

ok, noted, looking into removal of these files.

> May be this is not true for Linux developers but
> AFAIK autoconf/automake/libtool suite is way to achive platform
> independent software. Of course different Linux distros can also be
> defined as different platforms, but they are too similar if you look
> at the problem from BSD world point of view.

yep, thanks for bringing that view to us ;)

>
> --
> Nedko Arnaudov

---
ciaoTJ