On 22 March 2007 22:08, Brian Dessent wrote:
> The real problem seems to be that the libgcc is broken:
>
> configure:2121: /home/User/cvsroot/gcc-obj/./prev-gcc/xgcc
> -B/home/User/cvsroot/gcc-obj/./prev-gcc/
> -B/usr/local/i686-pc-cygwin/bin/
> conftest.c >&5
> /home/User/cvsroot/gcc-obj/./prev-gcc/libgcc.a(_ctors.o): In function
> `__sgetc_r':
> /usr/include/stdio.h:414: undefined reference to `_ungetc'
> /usr/include/stdio.h:410: undefined reference to `___srget_r'
> /usr/include/stdio.h:407: undefined reference to `___srget_r'
> collect2: ld returned 1 exit status
>
> It looks like a problem with some function being defined as a macro when
> it shouldn't, or vice versa. You'll need to look into how _ctors.o is
> built to see exactly, since I can't find any reference to _sgetc_r or
> ungetc in any of the libgcc2.{c,h} files. You can try the trick of
> going into the libgcc build directory (you may have to "make restage1"
> to back up one stage), "rm _ctors.o" and then "make CFLAGS="-g -O2
> -save-temps"" (or some variant) and then look at the preprocessed source
> to see what's happening.
This is what's happening:
configure, make all (fails), make stage1-bubble, cd i686-pc-cygwin/libgcc,
rm _ctors.o, make _ctors.o (optional), cd ../.., make all (succeeds).
This is how _ctors.o looks the first time:-
/gnu/gcc/obj2/i686-pc-cygwin/libgcc $ nm bad-one/_ctors.o
00000000 b .bss
00000000 d .data
00000000 N .stab
00000000 N .stabstr
00000000 t .text
00000010 C ___CTOR_LIST__
00000010 C ___DTOR_LIST__
00000000 t ___sgetc_r
U ___srget_r
U _ungetc
This is how it looks the second time:-
/gnu/gcc/obj2/i686-pc-cygwin/libgcc $ nm good-one/_ctors.o
00000000 b .bss
00000000 d .data
00000000 N .stab
00000000 N .stabstr
00000000 t .text
00000010 C ___CTOR_LIST__
00000010 C ___DTOR_LIST__
The source of the problem? From libgcc2.i after rebuilding _ctors.o:
# 1 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 1 "/gnu/gcc/obj/i686-pc-cygwin/libgcc//"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 32 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 1 "../.././gcc/tconfig.h" 1
[ ... snip ... ]
# 405 "/usr/include/stdio.h" 3 4
static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
{
int __c = (--(__p)->_r < 0 ? __srget_r(__ptr, __p) : (int)(*(__p)->_p++));
if ((__p->_flags & 0x4000) && (__c == '\r'))
{
int __c2 = (--(__p)->_r < 0 ? __srget_r(__ptr, __p) :
(int)(*(__p)->_p++));
if (__c2 == '\n')
__c = __c2;
else
ungetc(__c2, __p);
}
return __c;
}
# 487 "/usr/include/stdio.h" 3 4
# 91 "/gnu/gcc/gcc/libgcc/../gcc/tsystem.h" 2
Here's the bad build command diffed against the good build command:
--- a0 2007-03-25 00:27:08.556375000 +0000
+++ a1 2007-03-25 00:27:21.853250000 +0000
@@ -1,5 +1,5 @@
-#bad
+#good
/gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/
-B/gnu/install/i686-pc-cygwin/bin/ -B/gnu/install/i686-pc-cygwin/lib/ -isystem
/gnu/install/i686-pc-cygwin/include -isystem
/gnu/install/i686-pc-cygwin/sys-include
--g -fkeep-inline-functions -O2 -I/gnu/gcc/gcc/gcc/../winsup/w32api/include
-O2 -g -O2 -DIN_GCC
+-O2 -g -O2 -O2 -I/gnu/gcc/gcc/gcc/../winsup/w32api/include -O2 -g -O2
-DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -g -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED
--I. -I. -I../.././gcc -I/gnu/gcc/gcc/libgcc -I/gnu/gcc/gcc/libgcc/.
-I/gnu/gcc/gcc/libgcc/../gcc -I/gnu/gcc/gcc/libgcc/../include
-I/gnu/gcc/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _ctors.o -MT
_ctors.o -MD -MP -MF _ctors.dep -DL_ctors -c
/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c
+-I. -I. -I../.././gcc -I/gnu/gcc/gcc/libgcc -I/gnu/gcc/gcc/libgcc/.
-I/gnu/gcc/gcc/libgcc/../gcc -I/gnu/gcc/gcc/libgcc/../include
-I/gnu/gcc/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _ctors.o -MT
_ctors.o -MD -MP -MF _ctors.dep -DL_ctors -c
/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c
The critical difference is the presence or absence of
-fkeep-inline-functions. I think I remember there being some change between
gcc-3.x and gcc-4.x in inline handling and I think that's what's biting us
now; I think this may only arise in stage1 where we're trying to use 3.x to
compile 4.x.
What I dunno yet is why it doesn't just link against -lcygwin and pick up
the definitions of _ungetc and ___srget_r from there...
cheers,
DaveK
--
Can't think of a witty .sigline today....
