Bug 25035 - [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
Summary: [4.1/4.2 regression] libssp causes a failure with cross compilers with unifie...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: 4.1.3
Assignee: Not yet assigned to anyone
URL:
Keywords: build
: 28133 28596 (view as bug list)
Depends on:
Blocks: 28133
  Show dependency treegraph
 
Reported: 2005-11-25 18:22 UTC by berndtrog
Modified: 2014-02-16 13:17 UTC (History)
12 users (show)

See Also:
Host:
Target: host != target and unified build
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-05-07 08:51:22


Attachments
Patch to disable libssp for AVR target. (246 bytes, patch)
2008-02-12 19:38 UTC, Eric Weddington
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description berndtrog 2005-11-25 18:22:17 UTC
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?)
Comment 1 Andrew Pinski 2005-11-25 20:28:33 UTC
Actually IIRC libssp has some issues with cross compiling which needs to be fixed, anyways the workaround is --disable-libssp.
Comment 2 berndtrog 2005-12-05 19:06:20 UTC
Thats a 4.1/4.2 regression
Comment 3 Björn Haase 2006-01-03 15:33:56 UTC
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
Comment 4 Eric Weddington 2006-01-19 16:22:13 UTC
Bjoerne, could you post a comment to this bug that includes the link to the patch in the gcc-patches list?
Comment 5 Andrew Pinski 2006-05-07 08:51:22 UTC
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.
Comment 6 Mark Mitchell 2006-05-14 22:26:08 UTC
Where is the patch referenced in Comment #3?
Comment 7 Björn Haase 2006-05-15 17:25:38 UTC
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.  */
Comment 8 Mark Mitchell 2006-05-25 02:33:28 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 9 Vladimir Kondratyev 2006-06-23 12:09:58 UTC
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
Comment 10 Andrew Pinski 2006-06-28 21:16:46 UTC
*** Bug 28133 has been marked as a duplicate of this bug. ***
Comment 11 Eric Christopher 2006-07-24 05:51:21 UTC
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.
Comment 12 Andrew Pinski 2006-07-24 05:53:46 UTC
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.
Comment 13 David Edelsohn 2006-08-05 03:36:20 UTC
*** Bug 28596 has been marked as a duplicate of this bug. ***
Comment 14 Andrew Pinski 2006-08-18 04:18:23 UTC
This works for me with a cross (and sysroot) to powerpc-linux-gnu from a i686-linux-gnu.
Comment 15 Jorn Wolfgang Rennecke 2006-08-29 15:30:45 UTC
(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?
Comment 16 Andrew Pinski 2006-08-30 03:32:21 UTC
(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.
Comment 17 Eric Weddington 2006-08-30 21:13:03 UTC
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.
Comment 18 Joseph S. Myers 2006-09-29 21:19:02 UTC
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

Comment 19 Joseph S. Myers 2006-09-29 21:27:48 UTC
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

Comment 20 Andrew Pinski 2006-09-30 08:27:47 UTC
Fixed.
Comment 21 Rudolf Leitgeb 2008-02-12 18:27:14 UTC
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 ...
Comment 22 Eric Weddington 2008-02-12 19:38:18 UTC
Created attachment 15132 [details]
Patch to disable libssp for AVR target.
Comment 23 Eric Weddington 2008-02-12 19:43:16 UTC
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.
Comment 24 Rudolf Leitgeb 2008-02-13 08:45:23 UTC
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 :-(
Comment 25 Eric Weddington 2008-05-26 22:47:16 UTC
From Anatoly Sokolov:

[AVR][Committed] Disable building libssp for AVR
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00931.html

Comment 26 Jackie Rosen 2014-02-16 13:17:04 UTC Comment hidden (spam)