Hi, On Sat, Aug 22, 2009 at 02:42:04AM +0200, Cyril Brulebois wrote: > your package currently FTBFS on GNU/kFreeBSD because of a missing > HOST_NAME_MAX declaration. I've looked into the sys/syslimits.h headers, > but it turned out that it contains: > | /* > | * We leave the following values undefined to force applications to either > | * assume conservative values or call sysconf() to get the current value. > | * > | * HOST_NAME_MAX > | * > | * (We should do this for most of the values currently defined here, > | * but many programs are not prepared to deal with this yet.) > | */ > > As the failing build is examples/echo/echo-server.cpp, I assumed a quick > and dirty workaround might do, see the attached patch. FWIW, the > _POSIX_HOST_NAME_MAX #define is in /usr/include/bits/posix1_lim.h, > included through limits.h. > > Thanks for considering. > > Mraw, > KiBi.
> --- a/build-tree/dbus-c++/examples/echo/echo-server.cpp > +++ b/build-tree/dbus-c++/examples/echo/echo-server.cpp > @@ -9,6 +9,10 @@ > #include <stdio.h> > #include <limits.h> > > +#if !defined(HOST_NAME_MAX) && defined(_POSIX_HOST_NAME_MAX) > +#define HOST_NAME_MAX _POSIX_HOST_NAME_MAX > +#endif This looks wrong. It should be using sysconf() like the comment above suggests. If you disagree with what the comment says, you should be providing HOST_NAME_MAX via limits.h. Otherwise, let me know and I'll fix it to use sysconf() instead, it's a pretty easy fix. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
