This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Building an avr cross compiler from gcc-4_1-branch of today fails with: checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no Configuring in avr/libssp configure: creating cache ./config.cache checking build system type... i686-pc-linux-gnu checking host system type... avr-unknown-none checking target system type... avr-unknown-none checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for avr-strip... avr-strip checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no checking for avr-gcc... /tmp/obj/./gcc/xgcc -B/tmp/obj/./gcc/ -B/tmp/build/avr/bin/ -B/tmp/build/avr/lib/ -isystem /tmp/build/avr/include -isystem /tmp/build/avr/sys-include checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libssp] Fehler 1 make[1]: Leaving directory `/tmp/obj' make: *** [all] Fehler 2 Maybe libssp should be disabled for the avr target? (like mudflap?)
Actually IIRC libssp has some issues with cross compiling which needs to be fixed, anyways the workaround is --disable-libssp.
Thats a 4.1/4.2 regression
A patch for this issue is posted at the gcc-patches list and waits for review. The difficulty is that libssp silently assumes that unix-style stdio is available :-( which is not the case for embedded targets. Bjoern
Bjoerne, could you post a comment to this bug that includes the link to the patch in the gcc-patches list?
Confirmed, this has nothing really to do with AVR but all have to do with libssp fails with cross compilers. This has been report a couple of times to the list but nothing has been done about it yet for some reason.
Where is the patch referenced in Comment #3?
Subject: Re: [4.1/4.2 regression] libssp causes a failure with cross compilers mmitchel at gcc dot gnu dot org wrote on Montag, 15. Mai 2006 00:26 : > ------- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-14 22:26 > ------- Where is the patch referenced in Comment #3? Here it is. It seems that Bugzilla does not permit me to add more comments. Bjoern. PATCH: libssp, fix AVR bootstrap failure for gcc From: Björn Haase <bjoern.m.haase@web.de> To: gcc-patches@gcc.gnu.org Date: 30.12.2005 04:01 The code in /libssp/ssp.c implicitly assumes that the define symbols O_RDONLY and O_WRONLY exist. For the AVR target those are not defined in the header files included by ssp.c. Also the code does not work as expected for embedded targets that do not have "files" with the usual meaning. All of this causes a bootstrap failure for the AVR target. The patch adds #ifdefs as guards that first check for existing definitions of O_RDONLY and O_WRONLY before actually using them. After applying this change, bootstrap again succeeds. Bjoern. 2005-12-30  Bjoern Haase  <bjoern.m.haase@web.de>     * ssp.c: add "#ifdef" protections for symbols O_RDONLY and O_WRONLY Index: ssp.c =================================================================== --- ssp.c       (revision 109170) +++ ssp.c       (working copy) @@ -67,6 +67,8 @@   if (__stack_chk_guard != 0)    return;  +#ifdef O_RDONLY +   fd = open ("/dev/urandom", O_RDONLY);   if (fd != -1)    { @@ -77,6 +79,8 @@      return;    }  +#endif +   /* If a random generator can't be used, the protector switches the guard    to the "terminator canary".  */   p = (unsigned char *) &__stack_chk_guard; @@ -97,6 +101,8 @@    /* Print error message directly to the tty.  This avoids Bad Things    happening if stderr is redirected.  */ + +#ifdef O_WRONLY   fd = open (_PATH_TTY, O_WRONLY);   if (fd != -1)    { @@ -124,6 +130,7 @@      }     close (fd);    } +#endif   #ifdef HAVE_SYSLOG_H   /* Only send the error to syslog if there was no tty available.  */
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
I can confirm this bug. target=i386-pc-solaris2.10; host=i386-pc-linux-gnu; GCC 4.1.1; BinUtils 2.16.1 Checking multilib configuration... /bin/sh /home/anton/tmp/gcc/gcc-4.1.1/mkinstalldirs i386-pc-solaris2.10/libssp ; \ rm -f i386-pc-solaris2.10/libssp/Makefile || : ; \ cp multilib.out i386-pc-solaris2.10/libssp/multilib.out mkdir -p -- i386-pc-solaris2.10/libssp Configuring in i386-pc-solaris2.10/libssp configure: creating cache ./config.cache checking build system type... i386-pc-linux-gnu checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for i386-pc-solaris2.10-strip... i386-pc-solaris2.10-strip checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no checking for i386-pc-solaris2.10-gcc... /home/anton/tmp/gcc/objdir/./gcc/xgcc -B/home/anton/tmp/gcc/objdir/./gcc/ -B/opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/bin/ -B/opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/lib/ -isystem /opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/include -isystem /opt/crossgcc-4.1.1/solaris10-i386/gcc/i386-pc-solaris2.10/sys-include checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libssp] Error 1 make[1]: Leaving directory `/home/anton/tmp/gcc/objdir' make: *** [all] Error 2
*** Bug 28133 has been marked as a duplicate of this bug. ***
Is libssp even assumed to be OK for non-native targets? I think that it should probably be turned off by default on the embedded targets and just left that way.
It works, just the problem is that library's configure is incorrect, there have been threads about this issue which I cannot find right now.
*** Bug 28596 has been marked as a duplicate of this bug. ***
This works for me with a cross (and sysroot) to powerpc-linux-gnu from a i686-linux-gnu.
(In reply to comment #14) > This works for me with a cross (and sysroot) to powerpc-linux-gnu from a > i686-linux-gnu. > Is that a unified tree build with newlib?
(In reply to comment #15) > (In reply to comment #14) > > This works for me with a cross (and sysroot) to powerpc-linux-gnu from a > > i686-linux-gnu. > > > Is that a unified tree build with newlib? No it is not, it is a non unified tree at all, I have glibc and binutils already built before compiling the cross compiler.
Note that you cannot completely restrict this bug to "unified tree" builds. Building GCC 4.1.1 for the AVR target still fails unless one uses --disable-libssp, AND this is not a unified tree build. Binutils has been previously built, and in a seperate directory. The build order for the AVR target is: binutils, gcc, avr-libc; that's it.
Subject: Bug 25035 Author: jsm28 Date: Fri Sep 29 21:18:51 2006 New Revision: 117318 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117318 Log: PR other/25035 * configure.ac (AC_EXEEXT): Remove. (GCC_NO_EXECUTABLES): Call. (ssp_use_symver): Default to no if unable to link. (AC_CHECK_FUNCS): Hardwire results if unable to link. * aclocal.m4, configure, Makefile.in: Regenerate. Modified: trunk/libssp/ChangeLog trunk/libssp/Makefile.in trunk/libssp/aclocal.m4 trunk/libssp/configure trunk/libssp/configure.ac
Subject: Bug 25035 Author: jsm28 Date: Fri Sep 29 21:27:38 2006 New Revision: 117319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117319 Log: PR other/25035 * configure.ac (AC_EXEEXT): Remove. (GCC_NO_EXECUTABLES): Call. (ssp_use_symver): Default to no if unable to link. (AC_CHECK_FUNCS): Hardwire results if unable to link. * aclocal.m4, configure, Makefile.in: Regenerate. Modified: branches/gcc-4_1-branch/libssp/ChangeLog branches/gcc-4_1-branch/libssp/Makefile.in branches/gcc-4_1-branch/libssp/aclocal.m4 branches/gcc-4_1-branch/libssp/configure branches/gcc-4_1-branch/libssp/configure.ac
Fixed.
This bug has come to surface again ... again I have to use --disable-libssp when compiling gcc for the avr target, this time with gcc 4.2.3. Is ssp essential for avr that it keeps creeping in ? BTW: I use a separately compiled binutils package, so no unified tree here ...
Created an attachment (id=15132) [edit] Patch to disable libssp for AVR target.
Since 4.x, libssp has had to be disabled for the AVR. Libssp is not required for building the AVR. I've been meaning to reopen this bug report for a while. Patch for disabling libssp for the AVR target is attached.
Dear Eric, thanks for the patch, I already knew that one from here: http://winavr.cvs.sourceforge.net/winavr/patches/gcc/4.2.2/21-gcc-4.2.2-disable-libssp.patch?view=markup I just wanted to point out that I assumed from the previous communications that this bug was well known and understood, that libssp was not needed for the AVR platform and that I was puzzled why libssp was still enabled for avr. After messing around with gcc 4.2.3 for a while (and discovering that even old platforms like atmega2560 are unsupported) I reverted to 4.2.2 for which tons of patches are available. I have no idea why these patches were not merged into the 4.2.3 tree before its release ... some of them are many months old. If anyone sends me a list of patched which already have made it into 4.2.3, I'd offer volunteer help porting the remaing patches to 4.2.3 Sorry for my ramblings, but this whole winavr thing reminds me of the egcs story :-(
From Anatoly Sokolov: [AVR][Committed] Disable building libssp for AVR http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00931.html