[syslog-ng] 3.2 and 3.3 git experiences
Gergely Nagy
algernon at balabit.hu
Sat Nov 5 16:42:41 CET 2011
Peter Czanik <czanik at balabit.hu> writes:
> On 11/05/2011 03:25 PM, Gergely Nagy wrote:
>> Peter Czanik <czanik at balabit.hu> writes:
>>
>>> The above tests were done on a FreeBSD 8.1 machine. I'll do a quick test
>>> on FreeBSD 9 (the current cvs version) later this afternoon, as the
>>> Makefile seems to have v9 related fixes:
>>> .if ${OSVERSION} >= 900007
>>> @${REINPLACE_CMD} \
>>> -e 's|utmp|utmpx|' -e 's|getutent|getutxent|' \
>>> -e 's|ut_name|ut_user|' \
>>> ${WRKSRC}/configure ${WRKSRC}/modules/afuser/afuser.c \
>>> ${WRKSRC}/lib/utils.c ${WRKSRC}/lib/utils.h
>>> .endif
>> Wouldn't it be better if we turned this into a proper patch, so we
>> wouldn't need any patching at all?
>>
>> This kind of sed magic is... how can I put it gently? Horrible. I'll see
>> if I can come up with anything better.
> OK. There is nothing urgent. The above hack works, and 9.0 is not yet
> officially released. Let me know, if you have anything to test!
Hrm. Had a look at it, and it's not trivial to support this
properly. It's not hard, either, but non-trivial.
As far as I see, FreeBSD does not have getutent() (or getutxent) - at
least there's no manpage, and utmp(5) (on 8.2) doesn't mention getutent,
either. So we'll end up using our own implementation (in lib/utils.c and
lib/utils.h).
Changing configure and afuser is easy: we do an
AC_CHECK_HEADERS(utmpx.h), and add getutxent to AC_CHECK_FUNCS(). Then,
if we have HAVE_UTMPX_H defined, we include <utmpx.h>, and use struct
utmpx, otherwise we do the utmp stuff.
The wrapper is the harder cookie.
I would say, that the best would be to hide the utmp/utmpx stuff in a
wrapper, so there's only one place we litter with ifdefs. This is fairly
straightforward, but takes more time than I'm willing to spend on it.
So to the end of my TODO list it went. If there's any FreeBSD user here
on the list: this is an easy patch to make, and I'll happily help and/or
review patches. ;)
--
|8]
More information about the syslog-ng
mailing list