Very Computer

I've recently upgraded my 2.0.35 glibc5 system to glibc6 (2.0.6).  I tried
compiling a couple programs that use the socket headers.  I'm getting the
following errors:

-------------<snip>
(cd lib; make DEBUG="-O")
make[1]: Entering directory `/usr/src/lsof-4.33/lsof_4.33/lib'
gcc -O  -DLINUXV=20035 -DGLIBCV=2 -DHASUNMINSOCK=0 -DHASAX25CBPTR -DHASNETDEVICE_H -DKERN_LD_ELF -DHAS_FL_FILE -I/usr/src/linux/include   -c cvfs.c -o cvfs.o
gcc -O  -DLINUXV=20035 -DGLIBCV=2 -DHASUNMINSOCK=0 -DHASAX25CBPTR -DHASNETDEVICE_H -DKERN_LD_ELF -DHAS_FL_FILE -I/usr/src/linux/include   -c dvch.c -o dvch.o
gcc -O  -DLINUXV=20035 -DGLIBCV=2 -DHASUNMINSOCK=0 -DHASAX25CBPTR -DHASNETDEVICE_H -DKERN_LD_ELF -DHAS_FL_FILE -I/usr/src/linux/include   -c fino.c -o fino.o
In file included from /usr/include/sys/socket.h:34,
                 from /usr/include/netinet/in.h:24,
                 from ../dlsof.h:330,
                 from ../lsof.h:65,
                 from fino.c:52:
/usr/include/socketbits.h:71: warning: `PF_ROSE' redefined
/usr/src/linux/include/linux/socket.h:84: warning: this is the location of the previous definition
/usr/include/socketbits.h:78: warning: `PF_PACKET' redefined
/usr/src/linux/include/linux/socket.h:86: warning: this is the location of the previous definition
/usr/include/socketbits.h:95: warning: `AF_ROSE' redefined
/usr/src/linux/include/linux/socket.h:66: warning: this is the location of the previous definition
/usr/include/socketbits.h:102: warning: `AF_PACKET' redefined
/usr/src/linux/include/linux/socket.h:68: warning: this is the location of the previous definition
--------<snip>

It appears that /socketbits.h (which comes with glibc2.0.6) has some of the same defines as
socket.h (v2.0.35 kernel).  I know that these are only warnings but wanted to voice
it to the group here in case it's something more drastic.

Steve

--
"There are two types of light, the glow that illuminates, and the glare
that obscures."            -- James Thurber

Quote:>>>>> Stephen Costaras writes:

 > I've recently upgraded my 2.0.35 glibc5 system to glibc6 (2.0.6).  I tried
 > compiling a couple programs that use the socket headers.  I'm getting the
 > following errors:
 > [...]
 > /usr/include/socketbits.h:71: warning: `PF_ROSE' redefined
 > /usr/src/linux/include/linux/socket.h:84: warning: this is the location of the previous definition

 > It appears that /socketbits.h (which comes with glibc2.0.6) has some of the same defines as
 > socket.h (v2.0.35 kernel).  I know that these are only warnings but wanted to voice
 > it to the group here in case it's something more drastic.
Read the glibc FAQ that comes with glibc 2.0.6...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.5.    On Linux I've got problems with the declarations in Linux
        kernel headers.

{UD,AJ} On Linux, the use of kernel headers is reduced to the minimum.
This gives Linus the ability to change the headers more freely.  Also,
user programs are not insulated from changes in the size of kernel
data structures.

For example, the sigset_t type is 32 or 64 bits wide in the kernel.
In glibc it is 1024 bits wide.  This guarantees that when the kernel
gets a bigger sigset_t (for POSIX.1e realtime support, say) user
programs will not have to be recompiled.  Consult the header files for
more information about the changes.

Therefore you shouldn't include Linux kernel header files directly if
glibc has defined a replacement. Otherwise you might get undefined
results because of type conflicts.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

...and then don't include <linux/socket.h>

Andreas
--

Quote:>>>>>> Stephen Costaras writes:

>Therefore you shouldn't include Linux kernel header files directly if
>glibc has defined a replacement. Otherwise you might get undefined
>results because of type conflicts.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>...and then don't include <linux/socket.h>

This is generally true!  The lsof program, however, is a bit special in
that it needs to poke around in the kernel, and thus, for some structures
it needs the kernel definitions.  I would recommend to check the redhat
contribute archive to see if a pre-compiled lsof is already available,
and if not there check on Vic Abels web site at

//vic.cc purdu.edu/pub/tools/unix/lsof/binaries  

Vic, or someone else might already have solved this problem.

Villy

I've upgraded to glibc.2.06 and have problems making some applications.  The
error is:
In file included from /usr/include/linux/signal.h:5,
          from /usr/include/signal.h:28,
          from <my source.c>:nn:
/usr/include/asm/siginfo.h:48: parse error before `clock_t'
/usr/include/asm/siginfo.h:62: parse error before `}'
/usr/include/asm/siginfo.h:63: parse error before `}'

The obvious answer is that clock_t is undefined.  Including <time.h> fixes
the problem, but I'm wondering if there is something wrong in the headers
for 2.0.6.  No other platform requires me to include <time.h> in order to
compile a function using <signal.h>  Does a sanctioned fix exist ?  I've not
been able to find any information about the problem.  Am I the only one
having it ?

Zygmunt Wiercioch

Quote:>>>>> Zygmunt Wiercioch writes:

 > I've upgraded to glibc.2.06 and have problems making some applications.  The
 > error is:
 > In file included from /usr/include/linux/signal.h:5,
 >           from /usr/include/signal.h:28,
 >           from <my source.c>:nn:
 > /usr/include/asm/siginfo.h:48: parse error before `clock_t'
 > /usr/include/asm/siginfo.h:62: parse error before `}'
 > /usr/include/asm/siginfo.h:63: parse error before `}'

 > The obvious answer is that clock_t is undefined.  Including <time.h> fixes
 > the problem, but I'm wondering if there is something wrong in the headers
 > for 2.0.6.  No other platform requires me to include <time.h> in order to
 > compile a function using <signal.h>  Does a sanctioned fix exist ?  I've not
 > been able to find any information about the problem.  Am I the only one
 > having it ?

It seems that you didn't follow the glibc2 HowTo
<http://www.imaxx.net/~thrytis/glibc> and moved /usr/include away
before upgrading to glibc2 from libc5.  The <signal.h> file that comes
with glibc 2.0.6 doesn't include <linux/signal.h> - but the one from
libc5 does.

Andreas
--