[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktietz at gcc dot gnu.org

--- Comment #11 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-01-13 21:49:22 UTC ---
4.4.x gcc is now some time ago. But AFAIR the message you are showing here is,
that no crt was installed under your prefix.
Without the information from config.log I can't say much here.

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #12 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-12-17 22:02:33 UTC ---
I close this bug, as I can not reproduce it with 4.7, 4.6, and 4.5, and neither
so with 4.4.x. I close it as fixed, as this issue was orginal reported for
4.3.x, which has reached end of support AFAIK.

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[t66667 at gmail dot com]

------- Comment #10 from t66667 at gmail dot com  2009-08-20 08:53 -------
Hi, I try to build a gcc-4.4.1 cross compiler target x86_64-w64-mingw32 from
slackware linux 12.2 (i486-slackware-linux) and is getting the same error as
this report.

Checking multilib configuration for libstdc++-v3...
Configuring in x86_64-w64-mingw32/libstdc++-v3
configure: loading cache ./config.cache
checking build system type... i686-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking target system type... x86_64-w64-mingw32
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
...
checking for unistd.h... (cached) yes
checking for wchar.h... (cached) yes
checking for wctype.h... (cached) yes
checking for ld version... 21901
checking for ld that supports -Wl,--gc-sections... configure: error: Link tests
are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1

Tried attached patch "gcc-4.3.3-crosscompile-libstdc++.patch". Without success.

checking for ld version... 21901
checking for ld that supports --gc-sections... yes
checking for ld that supports -Wl,-z,relro... no
checking for sin in -lm... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[bkoz at gcc dot gnu dot org]

------- Comment #9 from bkoz at gcc dot gnu dot org  2009-04-27 23:16 -------

unfortunately, just assuming gc-sections work because `ld -v` shows gc-sections
won't fly: in the past this would have given false positives on some platforms.
This is different than the relro case.

Something to try might be

--host=i586-pc-linux-gnu

ie, trying to replicate #6's build success in 32-bit.


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[bero at arklinux dot org]

------- Comment #8 from bero at arklinux dot org  2009-02-05 20:14 -------
mkdir build
cd build
../configure --prefix=/usr --enable-static --enable-shared
--enable-fast-install --enable-c99 --enable-wchar_t --disable-gconf-peer
--target=i686-pc-mingw32 --enable-threads --enable-tls --with-tls
--enable-libstdcxx-pch --enable-__cxa_atexit
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-libada
--program-prefix=i686-pc-mingw32-
make -j4


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bero at arklinux dot org
                   |dot org                     |
             Status|WAITING                     |UNCONFIRMED


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-02-05 19:36 -------
Yes. Please add details about the way you are setting up your build, give
people a chance to analyse it.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[r dot emrich at de dot tecosim dot com]

------- Comment #6 from r dot emrich at de dot tecosim dot com  2009-02-05 16:34 -------
(In reply to comment #5)
> It does get called when building that i686-pc-linux-gnu -> i686-pc-mingw32
> crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
> the build system
> 

The cross build x86_64-unknown-linux-gnu -> i686-pc-mingw32 works fine for me.
Last build trunk revision 143920, but I also have a successful build of 4.3.3.
Indeed it indicates a wrong build setup.


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[bero at arklinux dot org]

------- Comment #5 from bero at arklinux dot org  2009-02-05 15:56 -------
It does get called when building that i686-pc-linux-gnu -> i686-pc-mingw32
crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
the build system


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2009-02-05 14:09 -------
But, isn't GLIBCXX_CHECK_LINKER_FEATURES called *only* when $GLIBCXX_IS_NATIVE?


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[bero at arklinux dot org]

------- Comment #3 from bero at arklinux dot org  2009-02-05 13:58 -------
Created an attachment (id=17247)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17247&action=view)
Proposed patch


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[bero at arklinux dot org]

------- Comment #2 from bero at arklinux dot org  2009-02-05 13:52 -------
A bit below the check for --gc-sections, GLIBCXX_CHECK_LINKER_FEATURES actually
checks for another linker feature in a way that doesn't break crosscompiling:

    cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"`
    if test -n "$cxx_z_relo"; then
      OPT_LDFLAGS="-Wl,-z,relro"
      ac_ld_relro=yes
    fi
    AC_MSG_RESULT($ac_ld_relro)


The same trick will work for gc-sections as well.


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[bero at arklinux dot org]

------- Comment #1 from bero at arklinux dot org  2009-02-05 13:50 -------
Since the purpose of the AC_TRY_LINK statement in libstdc++/acinclude.m4, line
260, is just to check if the linker barfs when given an argument, probably just
moving the GLIBCXX_CHECK_LINKER_FEATURES call to come before GCC_NO_EXECUTABLES
invocation should fix it.

Another possibility would be to just replace the AC_TRY_LINK call with
something along the lines of

if LANG=C $LD --gc-sections |grep -q "unrecognized option"; then
   # bad ld
else
   # good ld
fi


-- 


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