Multiple definition of 'struct sockaddr'

Bug #69838 reported by Richard Green
4
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Fix Released
Undecided
Matthias Klose

Bug Description

trying to compile Maiko's JNOS2 package:
www.physics.umanitoba.ca/~maiko/jnos2_fc5src.tar.gz
I get the following errors on both Dapper and Edgy systems:

gcc -DUNIX -g3 -DDEVELOPMENT -DDEBUG -W -Wimplicit -Wreturn-type -Wswitch -Wpointer-arith -Wcast-qual -Wcast-align -Waggregate-return -Wparentheses -I/usr/include/ncurses -DLCURSES=\"-lncurses\" -c -o tun.o tun.c
In file included from /usr/include/sys/socket.h:35,
                 from /usr/include/linux/if.h:22,
                 from tun.c:40:
/usr/include/bits/socket.h:43: error: syntax error before numeric constant
/usr/include/bits/socket.h:53: error: syntax error before numeric constant
In file included from /usr/include/sys/socket.h:35,
                 from /usr/include/linux/if.h:22,
                 from tun.c:40:
/usr/include/bits/socket.h:146: error: redefinition of ‘struct sockaddr’
make: *** [tun.o] Error 1

It appears these problems are in the libc6-dev header files, not his source.

Revision history for this message
Israel G. Lugo (ilugo) wrote :

I took a quick look at the program's source code, and they are doing a lot of definitions of system constants by themselves. For example, in socket.h line 79, they have:

#define SOCK_STREAM 0

This file is included from netuser.h:38, which is included from tcp.h:26, which is included from iface.h:21, which is included from tun.c:25. They also define struct sockaddr in their headers (in file sockaddr.h).

All of this happens before they include <linux/if.h> in (tun.c:40). As can be seen in your report, <linux/if.h> is including <sys/socket.h>, which will try to define the relevant data types and constants, and fail because they're already defined.

I was unable to reproduce the problem on Ubuntu Edgy, using libc6-dev 2.4-1ubuntu12.3 and linux-libc-dev 2.6.17.1-10.34. I downloaded the tar.gz from the URL you specified, and was able to successfully compile tun.c:

~/jnos2$ gcc --version
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/jnos2$ gcc -DUNIX -g3 -DDEVELOPMENT -DDEBUG -W -Wimplicit -Wreturn-type -Wswitch -Wpointer-arith -Wcast-qual -Wcast-align -Waggregate-return -Wparentheses -I/usr/include/ncurses -DLCURSES=\"-lncurses\" -c -o tun.o tun.c
~/jnos2$ ls tun.o
tun.o
~/jnos2$

Looking at my /usr/include/linux/if.h file, it does not include <sys/socket.h>. In fact, it includes <linux/socket.h>, which does practically nothing because almost all the inclusions and definitions are inside the following #if block:

#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)

None of those conditions are true when building the program, so the #if is never entered, so <linux/socket.h> does nothing (so there are no problems with redefining what JNOS already defined).

Your file /usr/include/linux/if.h seems to differ from mine. Which version of linux-libc-dev do you have? (that is the package which owns the headers from the Linux kernel, including the files located inside /usr/include/linux).

I would recommend you file this bug to the creators of the program. This seems to be a problem with their code; they probably did not test it against the particular version of linux headers you are using, and/or glibc.

Revision history for this message
Richard Green (rtg-aapsc) wrote : Re: [Bug 69838] Re: Multiple definition of 'struct sockaddr'
Download full text (3.4 KiB)

On Thu, 8 Feb 2007, Israel G. Lugo wrote:

> I was unable to reproduce the problem on Ubuntu Edgy, using libc6-dev
> 2.4-1ubuntu12.3 and linux-libc-dev 2.6.17.1-10.34. I downloaded the
> tar.gz from the URL you specified, and was able to successfully compile
> tun.c:
>
> ~/jnos2$ gcc --version
> gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> ~/jnos2$ gcc -DUNIX -g3 -DDEVELOPMENT -DDEBUG -W -Wimplicit -Wreturn-type -Wswitch -Wpointer-arith -Wcast-qual -Wcast-align -Waggregate-return -Wparentheses -I/usr/include/ncurses -DLCURSES=\"-lncurses\" -c -o tun.o tun.c
> ~/jnos2$ ls tun.o
> tun.o
> ~/jnos2$
>
> Looking at my /usr/include/linux/if.h file, it does not include
> <sys/socket.h>. In fact, it includes <linux/socket.h>, which does
> practically nothing because almost all the inclusions and definitions
> are inside the following #if block:
>
> #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
>
> None of those conditions are true when building the program, so the #if
> is never entered, so <linux/socket.h> does nothing (so there are no
> problems with redefining what JNOS already defined).
>
> Your file /usr/include/linux/if.h seems to differ from mine. Which
> version of linux-libc-dev do you have? (that is the package which owns
> the headers from the Linux kernel, including the files located inside
> /usr/include/linux).
>
  I don't have linux-libc-dev installed, and I do have libc6-dev version
2.3.6-0ubuntu20.4 on the dapper system that is giving me the problem.

I've experienced this on sevetral dapper systems, but just for jollies, I
started over on another dapper system, freshly updated with apt-get
update;apt-get upgrade;apt-get dist-upgrade,then installing gcc4,
build-essentials, and ncurses-dev. I downloaded the latest tarball of
jnos, and my first compile also failed with the multiple declaration
error.
   Then I ran `mv /etc/apt/sources.list /etc/apt/sources.dapper; sed
s/dapper/edgy/g /etc/apt/sources/dapper /etc/apt/sources.list`,
followed by `apt-get update; apt-get upgrade; apt-get dist-upgrade ;
apt-get dist-upgrade` Six hours later I was able to reboot into edgy,
re-attempt the compile, and see it complete successfully!
   So apparently the problem was fixed sometime during the edgy development
cycle. Hooray!

> I would recommend you file this bug to the creators of the program. This
> seems to be a problem with their code; they probably did not test it
> against the particular version of linux headers you are using, and/or
> glibc.
>
   According to the author:
Platforms successfully compiled, linked, and run on (so far) ...
Slackware 9.1 (my primary development environment) and Slackware 10.1
(reported by Gaston, LU5AGQ)
Red Hat 9, Enterprise Linux WS and AS, Fedora Core 1, 2, 3, and 4
Debian 3.0r3 (reported by Michel, VE2BCW) and Debian 3.1 (reported by
Rubn, EB5ESX)
Suse 9.2 (reported by Ian, G6VEY)
Mandrake 10.1 (reported by Larry, W5CQU)

Now compiles up to GCC versio...

Read more...

Revision history for this message
Matthias Klose (doko) wrote :

fixed in edgy and feisty.

Changed in glibc:
assignee: nobody → doko
status: Unconfirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.