I installed the NetBSD-current and freeradius 0.8.1 compiled without 
problems. The server is ok. 
Thanks the people who had answered mine e-mails. 

--
Daniel Dias Gonçalves
f22@netbsd.com.br

On Mon, 27 Jan 2003 13:07:47 -0500, David Maxwell <david@vex.net> wrote :

> On Sun, Jan 26, 2003 at 10:15:50AM -0800, Jason R Thorpe wrote:
> > On Sun, Jan 26, 2003 at 10:39:55AM -0000, Daniel Dias Gonçalves wrote:
> > 
> >  > I compiled freeradius 0.8.1 in NetBSD 1.6  but when I go run it 
> >  > the following error:
> >  > 
> >  > # radiusd
> >  > Sun Jan 26 10:22:39 2003 : Info: Starting - reading 
> >  > configuration files ...
> >  > /usr/local/lib/rlm_sql-0.8.1.so: Undefined PLT symbol "sem_init" 
> >  > (reloc type = 7, symnum = 54)
> >  > #
> > 
> > They're supported in NetBSD-current (1.6M and later), but not 1.6.
> 
> I asked Alan DeKok, primary maintainer of Freeradius:
> 
> Is sem_init needed - or only for sql backend support perhaps?
> 
> and he said to me:
> 
> They're used because they're simpler than pthread_mutex's.  They can
> (and should) be replaced with pthread_mutex calls.
> 
> 
> So, if I understand correctly, Freeradius uses semaphores because 
> (a) it needs to implement thread-safe locking in signal handlers
> (b) The semaphore API is significantly simpler than pthread_mutex
> (c) The Linux pthreads (currently do, but) won't guarantee signal
> 	delivery to the right thread.
> 
> I believe our pthreads does guarantee signal delivery to the right
> thread (over and above the POSIX spec, which doesn't require that) - and
> Alan says that if that's the case, he can #ifndef __NetBSD__ all of the
> semaphore code in the Freeradius distribution. 
> 
> I'll work with him to test that approach under 1.6 (where NetBSD pthreads
> don't apply) and -current.
> 
> -- 
> David Maxwell, david@vex.net|david@maxwell.net -->
> If you don't spend energy getting what you want,
> 	You'll have to spend it dealing with what you get.
> 					      - Unknown
> 
> 
>