Re: GNOME and glibc-2.3.4

[Kjartan Maraas <kmaraas broadpark no>]

man, 04,.04.2005 kl. 19.57 -0300, skrev Alexandre Hautequest:
> Hi folks.
> 
> First, sorry if this was discussed before here.
> 
> The majority of developers and distro's are using glibc-2.3.3 to write code.
> Unfortunately there's others -- i.e those from Slackware -current like myself
> -- who upgraded to glibc-2.3.4.
> 
I've been compiling using jhbuild with 2.3.4 with no problems. Is
slackware shipping bad user space headers maybe?


Cheers
Kjartan

> This updated glibc is raising a strange situation in some applications and GNOME
> code, specially those network-based: undefined structures, flags and variables
> not being correctly inserted.
> 
> As could be seen in this small compilation log (cvs from 04.04.2005),
> 
> make[2]: Entering directory `/home/hquest/cvs/gnome2/gnome-nettool/src'
> if gcc -DHAVE_CONFIG_H -I. -I. -I..
> -DGNOME_NETTOOL_LOCALEDIR=\""/opt/gnome2/share/locale"\"
> -DDATADIR=\""/opt/gnome2/share/gnome-nettool/dialogs/"\"
> -DPIXMAPS_DIR=\""/opt/gnome2/share/gnome-nettool/pixmaps"\" -DXTHREADS
> -D_REENTRANT -DXUSE_MTSAFE_API -D_XOPEN_SOURCE=500 -DORBIT2=1 -pthread
> -I/opt/gnome2/include/gtk-2.0 -I/opt/gnome2/lib/gtk-2.0/include
> -I/usr/X11R6/include -I/opt/gnome2/include -I/opt/gnome2/include/atk-1.0
> -I/opt/gnome2/include/pango-1.0 -I/usr/include/freetype2
> -I/opt/gnome2/include/glib-2.0 -I/opt/gnome2/lib/glib-2.0/include
> -I/opt/gnome2/include/libglade-2.0 -I/opt/gnome2/include/libxml2
> -I/opt/gnome2/include/gconf/2 -I/opt/gnome2/include/orbit-2.0      -g -O2
> -march=pentium4 -msse2 -mfpmath=sse -Wall -Wmissing-prototypes  -MT info.o -MD
> -MP -MF ".deps/info.Tpo" \
>   -c -o info.o `test -f 'info.c' || echo './'`info.c; \
> then mv -f ".deps/info.Tpo" ".deps/info.Po"; \
> else rm -f ".deps/info.Tpo"; exit 1; \
> fi
> info.c: In function `info_set_nic':
> info.c:98: warning: implicit declaration of function `strcmp'
> info.c: In function `info_get_interface_from_dev_name':
> info.c:133: warning: implicit declaration of function `strstr'

Needs #include <string.h>, this is included through some other header on
my system apparently...

> info.c: In function `info_get_nic_information':
> info.c:401: error: storage size of `ifc' isn't known
> info.c:402: error: storage size of `ifrcopy' isn't known

Should be ok since #include <net/if.h> is definitely there.

> info.c:448: warning: implicit declaration of function `bzero'

#include <strings.h>, but should really be using memset() instead.

> info.c:464: error: dereferencing pointer to incomplete type
> info.c:466: error: dereferencing pointer to incomplete type
> info.c:471: error: dereferencing pointer to incomplete type
> info.c:526: error: `IFF_UP' undeclared (first use in this function)
> info.c:526: error: (Each undeclared identifier is reported only once
> info.c:526: error: for each function it appears in.)
> info.c:533: error: `IFF_LOOPBACK' undeclared (first use in this function)
> info.c:550: error: `IFF_MULTICAST' undeclared (first use in this function)
> info.c:557: error: `IFF_POINTOPOINT' undeclared (first use in this function)
> info.c:401: warning: unused variable `ifc'
> info.c:402: warning: unused variable `ifrcopy'
> info.c: In function `info_get_interfaces':
> info.c:624: error: `IFF_UP' undeclared (first use in this function)
> make[2]: *** [info.o] Error 1
> make[2]: Leaving directory `/home/hquest/cvs/gnome2/gnome-nettool/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/hquest/cvs/gnome2/gnome-nettool'
> make: *** [all] Error 2
> 
> But all these "undeclared" errors are declared in <net/if.h>.
> 
Yeah, seems strange. Could it be broken toolchain on slackware? I only
ask because the latest Fedora Core has glibc-2.3.4 and I've had no
problems compiling from CVS here.

[snip other example]

> These same file compiles perfectly when used glibc-2.3.3 include files.
> 
> I don't know if GNU folks will accept this issue as a bug for glibc-2.3.4.
> 
Seems distro specific at least.

> While there's only a small part of people using this new glibc version, this is
> not a real big issue, but when major distros start to upgrade it, i see this as
> a real nightmare.
> 
> Any advice?
> 
File a bug against the slackware package first? Then see if it should be
moved upstream.

Cheers
Kjartan