[Bug c/56280] GCC builded for MinGW32(-w64) contains malformed directory in include search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56280
--- Comment #1 from Karlson2k 2013-02-11 00:29:26 UTC ---
With simple patch:
--- ./gcc/cppdefault.c.orig 2013-02-11 01:50:57 +0400
+++ ./gcc/cppdefault.c 2013-02-11 03:54:00 +0400
@@ -63,7 +63,7 @@ const struct default_include cpp_include
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
-{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 0, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
{ PREFIX_INCLUDE_DIR, 0, 0, 1, 0, 0 },
problem is fixed.
Test run with patch:
$ echo int main(){return 1;} | i686-w64-mingw32-gcc.exe -v -E -x c -
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc.exe
Target: i686-w64-mingw32
Configured with: ../../source/gcc-4.7.2/configure --build=i686-pc-mingw32
--host=i686-pc-mingw32 --target=i686-w64-mingw32 --disable-nls
--disable-multilib --prefix=/home/UserName/mingw-w64/mingw-w64-i686
--with-sysroot=/home/UserName/mingw-w64/mingw-w64-i686
--with-native-system-header-dir=/i686-w64-mingw32/include
--with-host-libstdcxx=/mingw/lib/gcc/mingw32/4.7.2/libstdc++.a
--disable-cloog-version-check --disable-ppl-version-check
--with-mpc=/home/UserName/mingw-w64/packages/gcc/packages/mpc/mpc-1.0.1-i686
--with-mpfr=/home/UserName/mingw-w64/packages/gcc/packages/mpfr/mpfr-3.1.1-i686
--with-gmp=/home/UserName/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686
--with-ppl=/home/UserName/mingw-w64/packages/gcc/packages/ppl/ppl-1.0-i686
--with-cloog=/home/UserName/mingw-w64/packages/gcc/packages/cloog-ppl/cloog-ppl-0.15.11-i686
--enable-languages=c,c++ --enable-threads=win32 --enable-fully-dynamic-string
--disable-sjlj-exceptions --with-multilib-list=m32 --with-arch=pentium3
--enable-leading-mingw64-underscores --with-dwarf2 --enable-lto
--disable-win32-registry --with-win32-nlsapi=unicode --enable-libstdcxx-debug
Thread model: win32
gcc version 4.7.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=pentium3'
t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../libexec/gcc/i686-w64-mingw32/4.7.2/cc1.exe
-E -quiet -v -iprefix
t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../lib/gcc/i686-w64-mingw32/4.7.2/
-isysroot
t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../../mingw-w64-i686
-U_REENTRANT - -mtune=generic -march=pentium3
ignoring duplicate directory
"T:/MinGW32/msys/1.0/home/UserName/mingw-w64/mingw-w64-i686/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.7.2/include"
ignoring duplicate directory
"t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.7.2/../../../../include"
ignoring duplicate directory
"T:/MinGW32/msys/1.0/home/UserName/mingw-w64/mingw-w64-i686/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.7.2/include-fixed"
ignoring duplicate directory
"T:/MinGW32/msys/1.0/home/UserName/mingw-w64/mingw-w64-i686/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory
"t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../../mingw-w64-i686/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../lib/gcc/i686-w64-mingw32/4.7.2/include
t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../include
t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../lib/gcc/i686-w64-mingw32/4.7.2/include-fixed
t:\mingw32\msys\1.0\home\username\mingw-w64\mingw-w64-i686\bin\../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include
End of search list.
# 1 ""
# 1 ""
# 1 ""
int main(){return 1;}
COMPILER_PATH=t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../libexec/gcc/i686-w64-mingw32/4.7.2/;t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../libexec/gcc/;t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../lib/gcc/i686-w64-mingw32/4.7.2/;t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../lib/gcc/;t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/lib/../lib/;t:/mingw32/msys/1.0/home/username/mingw-w64/mingw-w64-i686/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=pentium3'
[Bug c/56280] GCC builded for MinGW32(-w64) contains malformed directory in include search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56280 --- Comment #2 from Karlson2k 2013-02-11 00:32:16 UTC --- I didn't test it on other hosts, may be solution is a little more complex, like suggested in bug 56279 comment #1
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #23 from Karlson2k 2013-02-12 18:11:09 UTC --- Try to use LN_S_RECURSIVE:= instead of LN_S_RECURSIVE=
[Bug c/56368] New: GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368
Bug #: 56368
Summary: GCC Configure tests failed for name lister when
building from combined tree (GCC+Binutils)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k...@narod.ru
Host: i686-pc-mingw32
Target: i686-w64-mingw32, x86_64-w64-mingw32
Build: i686-pc-mingw32
When building gcc from combined sources tree, configure done some tests for
'${objdir}/../binutils/nm-new', but set 'objdir' later then tests.
>From config.log:
configure:12329: checking for BSD- or MS-compatible name lister (nm)
configure:12378: result: ${objdir}/../binutils/nm-new
configure:12508: checking the name lister (${objdir}/../binutils/nm-new)
interface
configure:12515: gcc -c -mms-bitfields -DTARGET_ALWAYS_STRIP_DOTDOT=true
-I/dvlp/mingw-w64-i686/include conftest.c >&5
configure:12518: /../binutils/nm-new "conftest.o"
/dvlp/packages/gcc/source/gcc-4.7.2/gcc/configure: line 12519:
/../binutils/nm-new: No such file or directory
configure:12521: output
configure:12528: result: BSD nm
configure:13469: checking command to parse ${objdir}/../binutils/nm-new output
from gcc object
configure:13587: gcc -c -I/dvlp/mingw-w64-i686/include conftest.c >&5
configure:13590: $? = 0
configure:13594: /../binutils/nm-new conftest.o \| sed -n -e 's/^.*[
]\([ABCDGISTW][ABCDGISTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)\{0,1\}$/\1 \2
\2/p' \> conftest.nm
/dvlp/packages/gcc/source/gcc-4.7.2/gcc/configure: line 13595:
/../binutils/nm-new: No such file or directory
configure:13597: $? = 0
cannot run sed -n -e 's/^.*[ ]\([ABCDGISTW][ABCDGISTW]*\)[ ][
]*\([_A-Za-z][_A-Za-z0-9]*\)
\{0,1\}$/\1 \2 \2/p'
configure:13587: gcc -c -I/dvlp/mingw-w64-i686/include conftest.c >&5
configure:13590: $? = 0
configure:13594: /../binutils/nm-new conftest.o \| sed -n -e 's/^.*[
]\([ABCDGISTW][ABCDGISTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)\{0,1\}$/\1 _\2
\2/p' \> conftest.nm
/dvlp/packages/gcc/source/gcc-4.7.2/gcc/configure: line 13595:
/../binutils/nm-new: No such file or directory
configure:13597: $? = 0
cannot run sed -n -e 's/^.*[ ]\([ABCDGISTW][ABCDGISTW]*\)[ ][
]*_\([_A-Za-z][_A-Za-z0-9]*\)
\{0,1\}$/\1 _\2 \2/p'
configure:13689: result: failed
configure:14712: checking for objdir
configure:14727: result: .libs
Test for 'objdir' should be done before any usage of 'objdir'.
[Bug c/56371] New: When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371 Bug #: 56371 Summary: When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld' Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@narod.ru Host: i686-pc-mingw32 Target: i686-w64-mingw32, x86_64-w64-mingw32, i686-pc-mingw32 Build: i686-pc-mingw32 When building from combined source tree, 'configure' detect binutils version and make some assumptions about gas based only on version, without making real tests. Quotes from 'config.log' with wrong assumptions (for combined tree): configure:21949: checking assembler for .literal16 configure:21976: result: yes . configure:22101: checking assembler for .nsubspa comdat configure:22129: result: yes . configure:22274: checking linker for .hidden support configure:22338: result: no . configure:22563: checking assembler for .sleb128 and .uleb128 configure:22611: result: no . configure:23630: checking assembler for thread-local storage support configure:23657: result: yes . configure:25977: checking assembler for dwarf2 debug_line support configure:26009: result: no . configure:26052: checking assembler for --gdwarf2 option configure:26080: result: no configure:26088: checking assembler for --gstabs option configure:26127: result: no . configure:26334: checking linker position independent executable support configure:26353: result: no . configure:26490: checking linker --as-needed support configure:26509: result: no Results of configure with pure GCC tree (binutils was build before GCC): configure:21949: checking assembler for .literal16 configure:21962: /mingw/mingw32/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:1: Error: unknown pseudo-op: `.literal16' configure:21965: $? = 1 configure: failed program was .literal16 configure:21976: result: no . configure:22101: checking assembler for .nsubspa comdat configure:22115: /mingw/mingw32/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:2: Error: unknown pseudo-op: `.nsubspa' configure:22118: $? = 1 configure: failed program was .SPACE $TEXT$ .NSUBSPA $CODE$,COMDAT configure:22129: result: no . configure:22274: checking linker for .hidden support configure:22338: result: yes . configure:22563: checking assembler for .sleb128 and .uleb128 configure:22582: /mingw/mingw32/bin/as-o conftest.o conftest.s >&5 configure:22585: $? = 0 configure:22611: result: yes . configure:23630: checking assembler for thread-local storage support configure:23643: /mingw/mingw32/bin/as --fatal-warnings -o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:2: Error: junk at end of line, first unrecognized character is `"' configure:23646: $? = 1 configure: failed program was .section ".tdata","awT",@progbits foo:.long25 .text movl%gs:0, %eax lealfoo@tlsgd(,%ebx,1), %eax lealfoo@tlsldm(%ebx), %eax lealfoo@dtpoff(%eax), %edx movlfoo@gottpoff(%ebx), %eax sublfoo@gottpoff(%ebx), %eax addlfoo@gotntpoff(%ebx), %eax movlfoo@indntpoff, %eax movl$foo@tpoff, %eax subl$foo@tpoff, %eax lealfoo@ntpoff(%ecx), %eax configure:23657: result: no . configure:25977: checking assembler for dwarf2 debug_line support configure:25991: /mingw/mingw32/bin/as-o conftest.o conftest.s >&5 configure:25994: $? = 0 configure:26009: result: yes . configure:26052: checking assembler for --gdwarf2 option configure:26066: /mingw/mingw32/bin/as --gdwarf2 -o conftest.o conftest.s >&5 configure:26069: $? = 0 configure:26080: result: yes configure:26088: checking assembler for --gstabs option configure:26102: /mingw/mingw32/bin/as --gstabs -o conftest.o conftest.s >&5 configure:26105: $? = 0 configure:26112: /mingw/mingw32/bin/as --gstabs -o conftest.o conftest.s 2>&1 | grep -i warning > /dev/null configure:26115: $? = 1 configure:26127: result: yes . configure:26334: checking linker position independent executable support configure:26353: result: yes . configure:26490: checking linker --as-needed support configure:26509: result: yes
[Bug c/56371] When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371 --- Comment #1 from Karlson2k 2013-02-17 23:12:26 UTC --- Too many differences to quickly predict what and where wrong, but most significant for me is 'thread-local storage'. Compiled GCC from combined tree don't have emulation for TLS and resulted GCC fail for build any program with 'static __thread'.
[Bug java/56372] New: Missing libgcj caused ICE (stack overflow) in jc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56372 Bug #: 56372 Summary: Missing libgcj caused ICE (stack overflow) in jc1 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@narod.ru Host: i686-pc-mingw32 Target: i686-w64-mingw32, x86_64-w64-mingw32 Build: i686-pc-mingw32 When building cross-compiler, this command caused stack overflow i686-pc-mingw32-gcj -o ecjx.exe -findirect-dispatch --main=org.eclipse.jdt.internal.compiler.batch.GCCMain ../../../../source/gcc-4.7.2/libjava/../ecj.jar ecjx.o That internally calls "t:/dvlp/mingw-w64-i686/libexec/gcc/i686-w64-mingw32/4.7.2/jc1.exe" "../../../../source/gcc-4.7.2/libjava/../ecj.jar" "-fhash-synchronization" "-fuse-divide-subroutine" "-fcheck-references" "-fuse-boehm-gc" "-fkeep-inline-functions" "-quiet" "-dumpbase" "ecj.jar" "-mtune=generic" "-march=pentium3" "-auxbase" "ecj" "-g1" "-findirect-dispatch" "-fbootclasspath=./;T:/dvlp/mingw-w64-i686/share/java/libgcj-4.7.2.jar" "-o" "C:\Users\UserName\AppData\Local\Temp\ccgbcsCW.s" If libgcj-4.7.2.jar is missing than jc1.exe is closed with error (stack overflow). Even with increased stack to 140 MB. Situation with missing libgcj is not valid, but I believe that jc1 must print some error message and not to crash.
[Bug c/56368] GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368 --- Comment #1 from Karlson2k 2013-02-19 16:41:03 UTC --- Looks like confusing naming. 'objdir' in 'configure' means 'relative path to directory for objects files', usually '.libs'. 'objdir' in makefile means 'absolute path to main build directory'. First few times 'objdir' in configure used like makefile's objdir and should be fixed.
[Bug ada/56271] GCC build errors when building ada and using LDFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56271 --- Comment #4 from Karlson2k 2013-02-20 21:29:06 UTC --- While this fix is OK in most cases, there is more correct fix. 'filter-out' use first argument as space separated list. Consider that WARN_CFLAGS is "-Wall -pedantic" (including double quotes). If any other variable has same words, for example CFLAGS was set to "-O3 -pedantic", that those words will be filtered out with quotes ( -pedantic" ) and 'make' will lose opening or closing quote. Better to use $(subst $(WARN_CFLAGS),,$(FLAGS_TO_PASS)) as it will replace whole string, not word by word.
[Bug c/56368] GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368 --- Comment #2 from Karlson2k 2013-02-22 15:44:42 UTC --- Created attachment 29524 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29524 Patch for configure for correct work with combined tree Apply patch + regenerate configure
[Bug c/56368] GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368 --- Comment #3 from Karlson2k 2013-02-22 15:49:37 UTC --- Seems that string objdir=$lt_cv_objdir was put to object directory detection script by mistake. 'objdir' is used in configure only for AR and NM and used in the same way like in 'Makefile'. My simple patch correct the this problem and correct configure errors.
[Bug c/56371] When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371
--- Comment #2 from Karlson2k 2013-02-22 15:59:56 UTC ---
There is bug in configure script. Just before 'checking linker for .hidden
support', configure detect ld version by:
if test $in_tree_ld != yes ; then
ld_ver=`$gcc_cv_ld --version 2>/dev/null | sed 1q`
if echo "$ld_ver" | grep GNU > /dev/null; then
if test x"$ld_is_gold" = xyes; then
[... cut ...]
fi
ld_date=`echo $ld_ver | sed -n
's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
else
case "${target}" in
[... cut ...]
esac
fi
fi
But in tree ld version is not detected at all!
Just a few lines later:
if test $in_tree_ld = yes ; then
gcc_cv_ld_hidden=no
if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge
13 -o "$gcc_cv_gld_major_version" -gt 2 \
&& test $in_tree_ld_is_elf = yes; then
gcc_cv_ld_hidden=yes
fi
else
configure make some assumption about ld basing on lv version.
As ld is build before run of gcc's configure, all detection could be unified
for in-tree ld and external ld.
[Bug libgcj/56435] New: Wrong 'ld' version detected during configuring libjava
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56435 Bug #: 56435 Summary: Wrong 'ld' version detected during configuring libjava Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@narod.ru >From configure.log: configure:19592: checking whether 'ld' is at least 2.13 configure:19606: result: yes; major=Binutils), minor=23 Seems that mingwld.m4 needs to be updated or replaced with newer script.
[Bug c/56371] When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371 --- Comment #4 from Karlson2k 2013-02-25 10:53:36 UTC --- Yes, it's related, but has more bugs to fix.
[Bug c/56371] When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371 --- Comment #5 from Karlson2k 2013-02-25 11:05:47 UTC --- With current configure some capabilities tests for in-tree gas and ld are based only on version (that's wrong, because for COFF many features (TLS) isn't supported), other tests require version and ELF target (again wrong, because some features (dwarf2) supported of COFF too) To workaround this, I've patched configure to make real tests on gas and ld even for combined tree as toplevel makefile build gas, ld and binutils before running gcc configure. But for real fix we need to patch autoconfigure files.
[Bug libstdc++/56475] New: Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 Bug #: 56475 Summary: Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@narod.ru Host: mingw32 Target: mingw32, mingw32-w64 When building native compiler for MinGW/MinGW-w64 'configure' checks for /dev/random simply by if test -r /dev/random && test -r /dev/urandom; then glibcxx_cv_random_tr1=yes; else glibcxx_cv_random_tr1=no; fi Result of this test is incorrect at least for MinGW. MinGW shell is executed in MSYS subsystem, so those devices is available for shell, but MinGW compiled programs will have no access to /dev/random. For some other platforms situation can be the same (/dev/random available for shell, but not for compiled program). I suggest to do a real compile-link-execute test instead of weak shell emulation.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #2 from Karlson2k 2013-02-27 19:28:17 UTC --- Better to open random devices with "rb"? Or just 'stat' device?
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #5 from Karlson2k 2013-02-27 22:07:21 UTC --- (In reply to comment #3) > Well, AC_TRY_RUN is for sure the wrong approach here. As such tests are > failing badly on cross-compilers. > I think sanest way to solve this is by special-casing mingw targets. This test is already skipped for cross-compilers and done only for native compilers. So AC_TRY_RUN is the only solution, that can check compiler's capabilities (and not the shell's).
[Bug libgcc/56482] New: missing -lpthread in configure when checking for pthreads_num_processors_np
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56482 Bug #: 56482 Summary: missing -lpthread in configure when checking for pthreads_num_processors_np Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@narod.ru Host: mingw32 Target: mingw32, mingw32-w64 >From configure.log: configure:20205: checking for pthreads_num_processors_np configure:20244: /dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/./gcc/xgcc -shared-libgcc -B/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/./gcc -nostdinc++ -L/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/i686-w64-mingw32/libstdc++-v3/src -L/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/i686-w64-mingw32/libstdc++-v3/src/.libs -L/dvlp/mingw-w64-i686/i686-w64-mingw32/lib -L/dvlp/mingw-w64-i686/mingw/lib -isystem /dvlp/mingw-w64-i686/i686-w64-mingw32/include -isystem /dvlp/mingw-w64-i686/mingw/include -B/dvlp/mingw-w64-i686/i686-w64-mingw32/bin/ -B/dvlp/mingw-w64-i686/i686-w64-mingw32/lib/ -isystem /dvlp/mingw-w64-i686/i686-w64-mingw32/include -isystem /dvlp/mingw-w64-i686/i686-w64-mingw32/sys-include -L/dvlp/packages/gcc/build/4.7.2-i686-w64-mingw32/./ld-o conftest.exe -g -O2 -fno-exceptions conftest.cpp >&5 C:\Users\Karlson\AppData\Local\Temp\ccd7ltCc.o: In function `main': T:\dvlp\packages\gcc\build\4.7.2-i686-w64-mingw32\i686-w64-mingw32\libstdc++-v3/conftest.cpp:76: undefined reference to `_imp__pthread_num_processors_np' collect2.exe: error: ld returned 1 exit status configure:20244: $? = 1 configure: failed program was: Configure didn't try with '-lpthread' flag, so result can't be linked with libpthread.
[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56482 --- Comment #2 from Karlson2k 2013-02-28 14:08:02 UTC --- If it'll be only compile test, how result can be linked when dependence on libpthread will be unknown?
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #10 from Karlson2k 2013-03-01 13:29:40 UTC --- Could you fix 4.7 branch too?
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #4 from Karlson2k 2013-03-03 10:25:47 UTC --- Created attachment 29569 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29569 Possible patch
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872
Karlson2k changed:
What|Removed |Added
CC||k2k at narod dot ru
--- Comment #5 from Karlson2k 2013-03-03 10:27:36 UTC ---
Simple patch is attached.
--- gcc/configure.ac.orig2012-09-13 17:32:31 +0400
+++ gcc/configure.ac2013-03-03 14:15:11 +0400
@@ -5117,15 +5117,15 @@ if test x"$enable_plugin" = x"yes"; then
AC_MSG_CHECKING([for exported symbols])
if test "x$export_sym_check" != x; then
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
-${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
-if $export_sym_check conftest | grep foobar > /dev/null; then
+${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest$ac_exeext > /dev/null
2>&1
+if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
: # No need to use a flag
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([yes])
AC_MSG_CHECKING([for -rdynamic])
- ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null
2>&1
- if $export_sym_check conftest | grep foobar > /dev/null; then
+ ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest$ac_exeext >
/dev/null 2>&1
+ if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
plugin_rdynamic=yes
pluginlibs="-rdynamic"
else
Should I sent it to mailing list?
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #7 from Karlson2k 2013-03-03 14:57:11 UTC --- (In reply to comment #6) > Yes, patch looks reasonable. Please sent it to patch ML. > This patch is small, so it is ok, but do you have already made paper-work with > FSF for gcc? This patch is simple as possible, to be quickly get it. But there are some space to improvement (like using standard macros, properly redirect error output). I'm not sure is it worth to work on it. To answer your question: no. What should I do?
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 Karlson2k changed: What|Removed |Added CC||k2k at narod dot ru --- Comment #16 from Karlson2k 2013-03-05 01:16:34 UTC --- Header version could be detected in _mingw_mac.h for MinGW-w64 or in _mingw.h for MinGW32. _mingw.h could be used for MinGW-w64 too as it include internally _mingw_mac.h.
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522 --- Comment #17 from Karlson2k 2013-03-05 01:28:06 UTC --- Created attachment 29582 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29582 Proposed patch Possible patch for latest MinGW-w64. Patched GCC version: 4.7.2 Can be easy edited for trunk version. --- ./libstdc++-v3/config/os/mingw32-w64/os_defines.h.orig2011-12-23 21:23:38 +0400 +++ ./libstdc++-v3/config/os/mingw32-w64/os_defines.h2013-03-05 05:22:07 +0400 @@ -64,7 +64,10 @@ #define _GLIBCXX_HAVE_DOS_BASED_FILESYSTEM 1 // See libstdc++/37522. +#include <_mingw_mac.h> +#if !defined (__MINGW64_VERSION_MAJOR) || (__MINGW64_VERSION_MAJOR < 3) #define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1 +#endif // See libstdc++/43738 // On native windows targets there is no ioctl function. And the existing
[Bug c/71983] New: "error: initializer element is not constant" only with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71983
Bug ID: 71983
Summary: "error: initializer element is not constant" only with
-O0
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: k2k at narod dot ru
Target Milestone: ---
Got error "error: initializer element is not constant" when following code is
compiled with '-O0'
int main(void)
{
static const int a = 1;
static const int b = 2;
static const int c = a + b;
return c;
}
If same code is compiled with -O1, -O2, -O3, -Ofast or even -Og, no errors and
no warnings are generated.
[Bug c/71983] "error: initializer element is not constant" only with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71983 --- Comment #2 from Karlson2k --- clang and MSVC accept this code. Inconsistency at different optimization levels is confusing and make harder to reveal errors in code.
[Bug libstdc++/56482] missing -lpthread in configure when checking for pthreads_num_processors_np
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56482 --- Comment #7 from Karlson2k --- Sorry, I can't check it, my build environment was lost a long time ago.
