Subject: Re: [ecasound] Porting ecasound to FreeBSD 4.2 (take 2)
From: Antoine Beaupre (LMC) (lmcabea@lmc.ericsson.se)
Date: Wed Dec 20 2000 - 17:59:43 EET
> On Tue, 19 Dec 2000, Anarcat wrote:
>
> Hmm, this is curious. The mlockall(2) man page says "Conforming to
> POSIX.1b, SVr4. SVr4 documents an additional EAGAIN error code.".
> But I guess for the moment, you can just use dirty tricks to get
> around the problem, ie. in libecasound/eca-session.cpp, comment the following
> section out:
>
> // if (::mlockall (MCL_CURRENT|MCL_FUTURE)) {
> // ecadebug->msg("(eca-session) Warning! Couldn't lock all memory!");
> // }
> // else
> // ecadebug->msg(ECA_DEBUG::system_objects, "(eca-session) Memory
> locked!");
>
> ... doesn't affect normal operation (code is triggered only when -r is
> specified).
Actually, what I did was to add a AC_CHECK_FUNCS(mlockall) macro to
configure.in. I got inspired from mysqld configuration (which would like
to use mlockall() too, but does not find it on fbsd).
#ifdef HAVE_MLOCKALL
if (::mlockall...
...
else
ecadebug...
#else
ecadebug->msg("(eca-session) Memory locking not available");
#endif
Is this proper?
Also, all this mlockall stuff confuses me. The function is not
documented anywhere, but _seems_ to be there. It's declared in
sys/mmap.h (I think) and surrounded by a #ifdef _POSIX..._VISIBLE, but
then if it wouldn't be declared, it would all fail before linking.
What confuses me is that the function implementation is not there, even
if the header is. I tried to grep a bit through FBSD source code and
found occurences of the call in the kernel binary, so it *has* to be
somewhere...
> > I find a lot of these messages confusing, as some are from libc.so!
> > I can understand that libc warns about uses of gets(), mktemp(),
>
> Yup, replaceing all *tmp() variants with stemp() on my todo-list.
That would be essential. And it's not that complex. I could spend some
time on that, or at least to make it compatible with fbsd's interfaces.
> gets() is a weird one, as I don't remember using it anywhere. I guess
> some of the libraries used by ecasound use it.
Wild guess: readline. How can we trace this back in another way than
grepping through the code?
> > I might have to check with fbsd people about these messages from
> > libc. They're weird. I never saw these elsewhere than when compiling
>
> > ecasound... There has to be something not nice done in there. :)
>
> Ok, if you get some info, I'd be interested to hear it also...
Yes. However, it now seems clearer to me that these are "regular"
compiler warnings. The trick is to find where they're from. At first, I
thought these would impede the library functions, but they're just
warnings after all.
Would you happen to know why it complains about f_prealloc()? Is it used
somewhere in the source?
However, the setkey() and such are not regular. Because setkey() *is*
present on my system. Since I don't think that ecasound uses a lot of
strong encryption, this is no big deal. :)
> > This is the result of a make in the source dir, without cleaning
> > it. And, by the way, on FreeBSD, the standard Make is BSD make, and
> > not GNU Make. And, of course, using bsd make breaks things:
> [...]
> > So it might just be a good idea to put a little message
> > like: "Remember to use GNU Make, often installed as gmake". Some put
>
> > it at the end of their configure script.
>
> Uhm, on the other hand, the same set of restrictions applies all apps
> using the GNU autoconf-automake-libtool combination. But I guess a
> warning wouldn't hurt. It's just that this might confuse some Linux
> folks ("gmake? but it doesn't work on my system, where can I get it?
> :)).
Yep. I've seen quite a few of these warnings. And, honestly, if someone
tries "gmake" without trying the "make" he always uses, and complains,
well.... you know, 'deserves it. :)
A.
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Dec 20 2000 - 18:07:28 EET