c/6013: GCC 3.0.4 cannot compile glib-2.0.0 on SunOS 5.5.1

Mario.Nigrovic@Motorola.COM Mario.Nigrovic@Motorola.COM
Wed Mar 20 06:11:00 GMT 2002

>Number:         6013
>Category:       c
>Synopsis:       GCC 3.0.4 cannot compile glib-2.0.0 on SunOS 5.5.1
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 20 04:36:01 PST 2002
>Originator:     Mario Nigrovic
>Release:        gcc-3.0.4
Solaris 2.5.1 (SunOS 5.5.1)

make            make-3.79.1
m4              m4-1.4
autoconf        autoconf-2.52
automake        automake-1.5
binutils        binutils-2.11.2
libiconv        libiconv-1.7
gettext         gettext-0.10.40         --with-libiconv-prefix=$release
bison           bison-1.33
flex            flex-2.5.4a
textutils       textutils-2.0.16
gperf           gperf-2.7.2
gcc             gcc-3.0.4               --with-gnu-as --with-as=$pfx/bin/as \
                                        --with-gnu-ld --with-ld=$pfx/bin/ld
libtool         libtool-1.4.2
cpio            cpio-2.4.2
diffutils       diffutils-2.7
fileutils       fileutils-4.1.1
gawk            gawk-3.1.0
grep            grep-2.4.2
less            less-374
patch           patch-2.5.4
sed             sed-3.02
texinfo         texinfo-4.1
wget            wget-1.8.1
pkgconfig       pkgconfig-0.12.0
Package glib uses an internal static structure to find
memory functions (malloc, etc), but somehow these are not
initialized correctly on 5.5.1.  The glib code exhibits
the same failings on Solaris 2.6 if gcc 2.95.[23] is used,
but gcc 3.0.4 fixed the issue on that architecture.

The configure code for various other packages contains a
snippit which should return the version of glib, but this
cores also.
Download glib-2.0.0 from www.gtk.org, then
configure --with-libiconv --prefix=/somewhere/else

Partway through the build, it tries to use glib-genmarshal,
but this program cores when it references g_strdup, which
references g_new, which is a macro for g_malloc, which gets
lost when it calls

mem = glib_mem_vtable.malloc (n_bytes);


More information about the Gcc-bugs mailing list