replying to my own message but I think I found a solution...
It seems that something was stale in /usr/include, I was able to
fix the problem by:
rm -rf /usr/include/*
cd /usr/src
make includes
cd /usr/src/lib/libc_r
make
make install
funny part is that two successive make worlds didn't seem to work, but
this did.
*shrug*
sorry for the noise,
-Alfred
On Mon, 4 Oct 1999, Alfred Perlstein wrote:
>
> On Mon, 4 Oct 1999, Marcel Moolenaar wrote:
>
> > Alfred Perlstein wrote:
> > >
> > > Since the signal changes...
> > >
> > > I'm finding that it _seems_ since libc_r isn't including something
> > > that properly defines __inline to inline that i'm getting unresolved
> > > symbols when linking or running programs that depend on libc_r.
> > >
> > > Anyone else getting this?
> > >
> > > compiling a void main(void){} with -pthread will barf for me,
> > > using -static I'm able to see which files are missing which
> > > inlines.
> >
> > This isn't a problem report I can deal with. Please be very explicit.
>
> I think it's something I may have broken somehow, but i'm not
> exactly sure:
>
> ~ % cat t.c
> #include <stdio.h>
>
> int main(void) {
>
> printf("hello world.\n");
>
> }
>
> .(14:17:52)(bright@thumper)
> ~ % gcc -static t.c -pthread
> /usr/lib/libc_r.a(uthread_sig.o): In function `_dispatch_signals':
> /home/src/lib/libc_r/uthread/uthread_sig.c(.text+0xf05): undefined reference to
>`__sigisempty'
>
> For some reason it looks like __inline is being defined like:
>
> #define __inline
>
> so that when signalvar.h is included the inlines for __sigisempty
> aren't getting the "inline_ prefix and are assumed to be somewhere
> else.
>
> I asked phk about it and he's not having the problem with a recent
> -current so I'll be futzing around searching for the reason this
> is happening.
>
> I just deleted my source tree and I'm going to re-check it out,
> maybe something got corrupted?
>
> -Alfred
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
