This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Building GCC 4.3.0 on Cygwin...


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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]