On Fri, 7 Jan 2000, Luoqi Chen wrote:
> > In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
> > (and later CFLAGS=-g3), but ran into linker problems as a result.
> >
> > blitz:~> gcc poll.c -pthread
> > /usr/lib/libc_r.so: undefined reference to `__sigisempty'
> >
> > Even the simplest of C programs will get this linker error if using the
> > -pthread option.
> >
> > So, __sigisempty is an inline function, defined in
> > /usr/include/sys/signalvar.h:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<sys/signalvar.h> should not be used outside of the kernel. Especially
not kernel inline functions in it. User servicable parts should be
in <signal.h>.
> > extern __inline int
^^^^^^
Bug. This also breaks compiling the kernel with -O. You apparently
clobbered -O in CFLAGS by setting CFLAGS=-g. -g normally needs to be
added to CC to avoid breaking CFLAGS (CC='cc -g').
> > __sigisempty(sigset_t *set)
> > {
> > int i;
> >
> > for (i = 0; i < _SIG_WORDS; i++) {
> > if (set->__bits[i])
> > return (0);
> > }
> > return (1);
> > }
> >
> It doesn't make much sense to have an "extern" inline function, gcc probably
> was confused by this, change "extern" to "static" and try again.
`extern' makes sense (see gcc.info), and is extensively used in Linux,
but usually it does the same things `static' except it breaks compiling
with -O. It prevents zillions of copies of the function being produced
(non-inline) in certain cases where inlining is not done (e.g., with
-O). A normal non-inline extern version of the function must be
provided to handle these cases. Sloppy use of `extern inline' doesn't
provide the extern function. Forcing use of the extern version may
be useful for profiling and similar instrumentation
(-finstrument-functions?), and for debugging.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
