Re: Current status of OpenBSD BEAST

[Nedko Arnaudov <nedko users sourceforge net>]

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.

Making all in docs
make[2]: Entering directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs'
Making all in generated
make[3]: Entering directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
make[4]: Entering directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
make[4]: *** No rule to make target `beast.1', needed by `all-am'.  Stop.
make[4]: Leaving directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs/generated'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/nedko/cvs/anoncvs.gnome.org/beast/docs'
make[1]: *** [all-recursive] Error 1

>> 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?

Not very experienced with dinamic libraries in unices but I expect "make
install" to install them in standard library path (it does) and then load
them from there. Here is some command output that may bring some light
to the problem:
nedko@titan ~
# ldconfig -r|grep sfi
        47:-lsfi.5.0 => /usr/local/lib/libsfi.so.5.0
        110:-lvorbisfile.3.0 => /usr/local/lib/libvorbisfile.so.3.0
        150:-lsfi-0.5.5.0 => /usr/local/lib/libsfi-0.5.so.5.0
        219:-lsfi-0.5.6.0 => /usr/local/lib/libsfi-0.5.so.6.0
        221:-lsfi.6.0 => /usr/local/lib/libsfi.so.6.0

nedko@titan ~
# ldconfig -r|grep bsw
        84:-lbsw-0.5.5.0 => /usr/local/lib/libbsw-0.5.so.5.0
        132:-lbsw.5.0 => /usr/local/lib/libbsw.so.5.0
        240:-lbsw-0.5.6.0 => /usr/local/lib/libbsw-0.5.so.6.0
        244:-lbsw.6.0 => /usr/local/lib/libbsw.so.6.0

nedko@titan ~
# which beast
/usr/local/bin/beast

nedko@titan ~
# beast
beast: can't load library '../sfi/.libs/libsfi.so.6.0'

Other possibility may be to load it from fixed absolute path.

However all these problems may be related to libtool. Any help will be
very appreciated.

>> >> -#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.

Agreed, issue goes to "common build environment" status (see below)

>> >> -  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"?

Common build environment means that patching autoconf/automake/libtool
system iteself is not required to build BEAST on OpenBSD.

>> >> -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.

OpenBSD grep actually supports -q
It does not support \b in regexps

Any autoconf version that is available for OpenBSD is better for me.
>From others, the newer is better for me unless you think otherwise. So
far I've not found autoconf related issues.

>> 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?
Checking for extact version like the one for libtoolize in patch I
submited before seems more appropriate for me. Checking for some
version or newer can be made by running sed on tool version output
and then comparing the result using arithmetic comparison.

>> >> -#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"

aclocal.m4 is produced from your local m4 macros and I suspect that one
of them sets SED in aclocal.m4 and then in configure script. This
actually leads to broken libtool. Setting SED environment vaiable is not
hard of course but it is starnge thing to do. More serious reason to not
using fixed libtool is that there can be more problems that dont lead to
unability to build beast, but to some other problem. However I am not
aware of such problem at the moment. So if you want fixed libtool you
should ensure that m4 macros related to it are also fixed.

>> > 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 ;)

I already said why I included them, because I made and sent patch and
not shell script that makes beast use autoconf 2.58 and libtool 1.5
The only way that I've found was the one -N option to diff. If smart
shell scripts that patch beast sources are acceptable for BEAST
community, this is something new to me. However wide use of diff/patch
suite has reasonable background AFAIK. This is the reason.

>> > 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?

Requirement to set SED environment variable. However SED case is only
side effect. The generic platform independecy is more importat IMHO.

>> 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.

Cool :)

-- 
Nedko Arnaudov