[Bug c/48264] New: Simple dummy program fails with Segmentation Fault upon -shared linking

2011-03-23 Thread leo.izen at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48264



   Summary: Simple dummy program fails with Segmentation Fault

upon -shared linking

   Product: gcc

   Version: 4.5.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: leo.i...@gmail.com





Here's my output of gcc -v:



Using built-in specs.

COLLECT_GCC=/usr/bin/gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.5.1/lto-wrapper

Target: x86_64-redhat-linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man

--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla

--enable-bootstrap --enable-shared --enable-threads=posix

--enable-checking=release --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-gnu-unique-object

--enable-linker-build-id

--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin

--enable-java-awt=gtk --disable-dssi

--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre

--enable-libgcj-multifile --enable-java-maintainer-mode

--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib

--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686

--build=x86_64-redhat-linux

Thread model: posix

gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) 



I make a simple C program, compiled it an ran it. If I link it with -shared, it

segfaults, as in:



[Leo@chessman ~]$ cat test.c

int main(void) {

return 0;

}

[Leo@chessman ~]$ gcc -c -o test.o test.c

[Leo@chessman ~]$ gcc -o test test.o

[Leo@chessman ~]$ ./test

[Leo@chessman ~]$ gcc -shared -o test test.o

[Leo@chessman ~]$ ./test

Segmentation fault (core dumped)

[Leo@chessman ~]$



I assume that this is a bug in collect2 and not cc1 given that linking

differently fixed it, but I would like to link with -shared so this is sort of

annoying.


[Bug c/46421] New: fatal error: stdio.h: No such file or directory

2010-11-10 Thread leo.izen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46421

   Summary: fatal error: stdio.h: No such file or directory
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo.i...@gmail.com


Created attachment 22370
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22370
The complete output from the make command

I was building a cross compiler for x86_64-pc-mingw32 on Fedora core 14.

Configured with:

../configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
--target=x86_64-pc-mingw32 --with-gnu-as --with-gnu-ld --verbose
--disable-win32-registry --enable-version-specific-runtime-libs
--enable-languages=c,c++,objc,obj-c++,fortran


Soon after the xgcc was built, it tried compiling cygming.h, and I got the
error in the summary. 

I ran make clean, then ran make >make-log.txt 2>&1
The make-long.txt is attached.


[Bug c/26749] too few arguments to function va_start is caught too late

2010-11-10 Thread leo.izen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26749

Leo Izen  changed:

   What|Removed |Added

 CC||leo.izen at gmail dot com

--- Comment #1 from Leo Izen  2010-11-11 01:50:19 
UTC ---
va_start is a macro, is that why?


[Bug c/46421] fatal error: stdio.h: No such file or directory

2010-11-11 Thread leo.izen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46421

--- Comment #2 from Leo Izen  2010-11-11 20:11:35 
UTC ---
(In reply to comment #1)
> Invalid, you need the mingw32 headers installed.

How do I get these?