[Bug libstdc++/52169] New: the ifstream readsome() method does not signal any bit on eof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
Bug #: 52169
Summary: the ifstream readsome() method does not signal any bit
on eof.
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: virik...@gmail.com
Created attachment 26608
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26608
Run it with ./c2 c2.cpp and it will loop forever
The ifstream readsome() method does not signal any bit on eof, and I think it
should.
Therefore, these loops loop forever:
while(f !f.eof())
{
char b[5000];
size_t read = f.readsome(b, sizeof b);
cerr Read: read bytes endl;
ostr.write(b, read);
}
According to http://www.cplusplus.com/reference/iostream/istream/readsome/ :
Errors are signaled by modifying the internal state flags:
eofbitThe get pointer is at the end of the stream buffer's internal input
array when the function is called, meaning that there are no positions to be
read in the internal buffer (which may or not be the end of the input
sequence). This happens when rdbuf()-in_avail() would return -1 before the
first character is extracted.
failbitThe stream was at the end of the source of characters before the
function was called.
badbitAn error other than the above happened.
[Bug libstdc++/52169] the ifstream readsome() method does not signal any bit on eof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169 --- Comment #3 from Lluís Batlle i Rossell viriketo at gmail dot com 2012-02-08 10:53:20 UTC --- It looks also related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8258 . The post from Tomalak and that made all clear. Sorry for the noise!
[Bug c++/46147] New: g++ segfault compiling gnat 0.8.8 on mips-linux n32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46147 Summary: g++ segfault compiling gnat 0.8.8 on mips-linux n32 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: virik...@gmail.com Created attachment 22132 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22132 The preprocessed source causing the trouble. At the middle of building gnat 0.8.8 (with boost 1.44.0) g++ dies with an internal error related to a segmentation fault. I'm using gcc 4.5.1 with glibc 2.12.1 in a mips64-linux running n32 userland code, and binutils from a snapshot of the end of august (for the loongson2f fix). The gcc is built, as a special flag, with --with-arch=loongson2f. I attach the preprocessed file that triggers the error. Compile the file with the same flags the gnash build system decided: g++ -g -O2 -fvisibility-inlines-hidden -fPIC -c Removing only -fPIC, the problem goes away. Using -O0 instead, also makes the problem go away. Removing only -fvisibility-inlines-hidden also makes the problem go away. The system has 1GiB of RAM, and monitoring with 'top', I see g++ never goes beyond 300MiB.
[Bug c++/45541] New: Internal error (killed) building webkit svn 65398 (loongson2f)
/include/glib-2.0 -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/lib/glib-2.0/include -I/nix/store/05gz27jsn9h5l9v0k5x5smbsxfrvxpyn-atk-1.30.0/include/atk-1.0 -I/nix/store/qmlqflagj8z0gk1dh6l61dsjnjy08k6k-cairo-1.8.10/include/cairo -I/nix/store/w38gr4g7h37hmz8rh5d1zfyl96byjpr1-freetype-2.4.1/include/freetype2 -I/nix/store/w38gr4g7h37hmz8rh5d1zfyl96byjpr1-freetype-2.4.1/include -I/nix/store/zmk5dxd9ziigs508nmycjwby2d9gw1xz-fontconfig-2.8.0/include -I/nix/store/yrgqdxq96mdf4ghvikb3b8ngy0f8825f-pango-1.28.1/include/pango-1.0 -pthread -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/include/glib-2.0 -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/lib/glib-2.0/include -pthread -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/include/glib-2.0 -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/lib/glib-2.0/include -I/nix/store/igysbxjyp7d22i23qr1gwag2n75wylnp-libxml2-2.7.7/include/libxml2 -I/nix/store/s8r0najhda70p0ldkg2pm04kyzxg8by0-gstreamer-0.10.30/include/gstreamer-0.10 -I/nix/store/aimr99a0a6pw212xyy5ddwm94lx0vmi8-gst-plugins-base-0.10.30/include/gstreamer-0.10 -pthread -I/nix/store/yh1ia9ga0fwdcvnixbggzmyqcwdrvcwg-gtk+-2.20.1/include/gtk-2.0 -I/nix/store/yh1ia9ga0fwdcvnixbggzmyqcwdrvcwg-gtk+-2.20.1/lib/gtk-2.0/include -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/include/glib-2.0 -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/lib/glib-2.0/include -I/nix/store/05gz27jsn9h5l9v0k5x5smbsxfrvxpyn-atk-1.30.0/include/atk-1.0 -I/nix/store/qmlqflagj8z0gk1dh6l61dsjnjy08k6k-cairo-1.8.10/include/cairo -I/nix/store/w38gr4g7h37hmz8rh5d1zfyl96byjpr1-freetype-2.4.1/include/freetype2 -I/nix/store/w38gr4g7h37hmz8rh5d1zfyl96byjpr1-freetype-2.4.1/include -I/nix/store/zmk5dxd9ziigs508nmycjwby2d9gw1xz-fontconfig-2.8.0/include -I/nix/store/yrgqdxq96mdf4ghvikb3b8ngy0f8825f-pango-1.28.1/include/pango-1.0 -pthread -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/include/glib-2.0 -I/nix/store/mvxmr92995ypr60vrsnzmrfwa54dwhhg-glib-2.24.1/lib/glib-2.0/include -I/nix/store/sjxy9x2j126lx755ni9iihkvp9flmalj-libsoup-2.31.2/include/libsoup-2.4 -I/nix/store/igysbxjyp7d22i23qr1gwag2n75wylnp-libxml2-2.7.7/include/libxml2 -I/nix/store/igysbxjyp7d22i23qr1gwag2n75wylnp-libxml2-2.7.7/include/libxml2 -I/nix/store/xfdlyys8y23kmw2vsgqjd3091p6iip7d-libxslt-1.1.26/include -I/nix/store/xxa55gs23hzc4axqajl0hq72h926h7rm-sqlite-3.7.2/include -D_REENTRANT -I/nix/store/i6iyplb7x2rzhnlf9v5bsib1n1y5rgld-icu4c-4.5.1/include -O2 -MT WebCore/bindings/js/libwebkitgtk_1_0_la-SerializedScriptValue.lo -MD -MP -MF WebCore/bindings/js/.deps/libwebkitgtk_1_0_la-SerializedScriptValue.Tpo -c WebCore/bindings/js/SerializedScriptValue.cpp -fPIC -DPIC -o WebCore/bindings/js/.libs/libwebkitgtk_1_0_la-SerializedScriptValue.o The gcc has been built with --with-arch=loongson2f. -- Summary: Internal error (killed) building webkit svn 65398 (loongson2f) Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: mips64-unknown-linux-gnu GCC host triplet: mips64-unknown-linux-gnu GCC target triplet: mips64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45541
[Bug c++/45541] Internal error (killed) building webkit svn 65398 (loongson2f)
--- Comment #2 from viriketo at gmail dot com 2010-09-05 09:33 --- This is what I thought first. The computer has 1GB of RAM, 900MB free at the time of the build. After that failure, I added 500MiB of swap. I tried to build, and it halted in the same place with the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45541
[Bug c++/45541] Internal error (killed) building webkit svn 65398 (loongson2f)
--- Comment #3 from viriketo at gmail dot com 2010-09-05 13:02 --- Yes OOM killed cc1plus, but maybe it is g++ taking far too much memory? [157723.444000] cc1plus invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0 [157723.444000] Call Trace: [157723.444000] [80216a60] dump_stack+0x8/0x40 [157723.444000] [802a7040] dump_header.clone.13+0x70/0x198 [157723.444000] [802a71f4] oom_kill_process.clone.14+0x8c/0x130 [157723.444000] [802a77ac] __out_of_memory+0x144/0x228 [157723.444000] [802a7c04] out_of_memory+0x6c/0x128 [157723.444000] [802ac4d4] __alloc_pages_nodemask+0x5f4/0x608 [157723.444000] [802c2f34] handle_mm_fault+0x94c/0xce0 [157723.444000] [8022f5b4] do_page_fault+0x194/0x328 [157723.444000] [80200404] ret_from_exception+0x0/0x10 [157723.444000] [157723.444000] Mem-Info: [157723.444000] Normal per-cpu: [157723.444000] CPU0: hi: 42, btch: 7 usd: 29 [157723.444000] active_anon:46147 inactive_anon:15397 isolated_anon:0 [157723.444000] active_file:12 inactive_file:2 isolated_file:0 [157723.444000] unevictable:739 dirty:0 writeback:0 unstable:0 [157723.444000] free:359 slab_reclaimable:213 slab_unreclaimable:1083 [157723.444000] mapped:5 shmem:0 pagetables:163 bounce:0 [157723.444000] Normal free:5744kB min:5776kB low:7216kB high:8656kB active_anon:738352kB inactive_anon:246352kB active_file:192kB inactive_file:32kB unevictable:11824kB isolated(anon):0kB isolated(file):0kB present:2086400kB mlocked:0kB dirty:0kB writeback:0kB mapped:80kB shmem:0kB slab_reclaimable:3408kB slab_unreclaimable:17328kB kernel_stack:2320kB pagetables:2608kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:102 all_unreclaimable? yes [157723.444000] lowmem_reserve[]: 0 0 [157723.444000] Normal: 359*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 5744kB [157723.444000] 3692 total pagecache pages [157723.444000] 2939 pages in swap cache [157723.444000] Swap cache stats: add 32538, delete 29599, find 0/0 [157723.444000] Free swap = 0kB [157723.444000] Total swap = 520608kB [157723.46] 65536 pages RAM [157723.46] 921 pages reserved [157723.46] 48 pages shared [157723.46] 64196 pages non-shared [157723.46] Out of memory: kill process 31075 (g++) score 44376 or a child [157723.46] Killed process 31076 (cc1plus) vsz:1411216kB, anon-rss:932624kB, file-rss:64kB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45541
[Bug c++/45541] Internal error (killed) building webkit svn 65398 (loongson2f)
--- Comment #5 from viriketo at gmail dot com 2010-09-05 21:09 --- Created an attachment (id=21705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21705action=view) Preprocessed source causing the trouble I attach the preprocessed file that triggers the problem. In this case, it ended in Segmentation Fault, when using the preprocessed file. Maybe sometimes the OOM kills, sometimes it segfaults. In any case, I have not seen monitoring with 'top' a memory usage beyond 150MB. Here is the command line triggering the trouble: g++ -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -fvisibility=hidden -fvisibility-inlines-hidden -fno-rtti -fno-strict-aliasing -pthread -O2 -c -fPIC -c file.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45541
[Bug target/43944] libgcc2 fails to build in gcc 4.5.0
--- Comment #4 from viriketo at gmail dot com 2010-08-03 21:31 --- I still see the problem in gcc 4.5.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
[Bug target/43944] libgcc2 fails to build in gcc 4.5.0
--- Comment #3 from viriketo at gmail dot com 2010-05-01 13:46 --- I just tested the bootstrap *not profiled*, and it works perfectly. Building a cross compiler from x86_64-unknown-linux to armv5tel-unknown-linux-gnueabi also works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
[Bug target/43944] libgcc2 fails to build in gcc 4.5.0
--- Comment #2 from viriketo at gmail dot com 2010-04-30 16:32 --- (In reply to comment #1) Err, so what is the configuration and what are you trying to do ? It sounds like you are trying to do a profiled bootstrap. Is that the case ? Sorry, I thought that the information I pasted would be enough for you to reproduce the bug. I'll try to add the information: gcc version: 4.5.0, compiling it with gcc 4.4.3 + glibc 2.11.1 system type: armv5tel-unknown-linux-gnueabi options configuring: --disable-multilib --with-ppl=...(ppl-0.10.2) --with-cloogppl=...(cloog-ppl-0.15.7) --with-gmp=...(gmp-4.3.2) --with-mpfr=...(mpfr-2.4.2) --with-mpc=...(0.8.1) --with-libelf=...(0.8.13) --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-languages=c,c++ make arguments: profiledbootstrap I wanted to build a native compiler profiled, and bootstrapped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
[Bug other/43944] New: libgcc2 fails to build in gcc 4.5.0
Here is the concerning part of the log. In all-stageprofile-target-libgcc: building _moddi3.o ... ../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function '__moddi3': ../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c:1103:1: error: total size of local objects too large The same kind of configuration built properly with gcc 4.4.3 -- Summary: libgcc2 fails to build in gcc 4.5.0 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: armv5tel-unknown-linux-gnueabi GCC host triplet: armv5tel-unknown-linux-gnueabi GCC target triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
[Bug libgomp/43194] New: Error building libgomp shared
I'm building a cross toolchain for ultrasparc, and when I build the final gcc (with a proper glibc 2.11.1 built), I get: checking for C compiler default output file name... configure: error: in `/tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/build/sparc64-unknown-linux/libgomp': configure: error: C compiler cannot create executables Config.log shows: $ /tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/gcc-4.4.3/libgomp/configure --cache-file=./config.cache --with-cross-host=x86_64-unknown-linux-gnu --prefix=/nix/store/hvbynr246lx5ajxd2akvs4ry3ns90py3-gcc-4.4.3-sparc64-unknown-linux-stage-final --disable-multilib --with-ppl=/nix/store/mb40dibxpvnx57xbddnzdvy2hxnnipp9-ppl-0.10.2 --with-cloog=/nix/store/4ffjd1j014rn91bckprbyz2zl7r7fc6i-cloog-ppl-0.15.7 --with-gmp=/nix/store/00fbkpgn2g1xrp39crrvnyjb2kj3m6js-gmp-4.3.2 --with-mpfr=/nix/store/dzqizzqfaalqdxv1a0sy9zv2w2w8f5nq-mpfr-2.4.2 --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --with-cpu=ultrasparc --with-headers=/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/include --enable-__cxa_atexit --enable-long-long --enable-threads=posix --enable-nls --enable-languages=c,c++ --program-transform-name=s,^,sparc64-unknown-linux-, --with-target-subdir=sparc64-unknown-linux --build=x86_64-unknown-linux-gnu --host=sparc64-unknown-linux --target=sparc64-unknown-linux --srcdir=../../../gcc-4.4.3/libgomp configure:2569: checking for C compiler default output file name configure:2572: /tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/build/./gcc/xgcc -B/tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/build/./gcc/ -g0 -O2 -B/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/lib -idirafter /nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/include -Wl,-L/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/lib -g0 -O2 -B/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/lib -idirafter /nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/include -Wl,-L/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/lib -g0 -O2 -B/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/lib -idirafter /nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/include -Wl,-L/nix/store/gvr35zv0b7155fwxx4gd6yqcmkrkx2rn-glibc-2.11.1-sparc64-unknown-linux/lib conftest.c 5 /tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/build/./gcc/cc1: error while loading shared libraries: /tmp/nix-build-fg665ygndf0l90symznxdarn7cpffbhz-gcc-4.4.3-sparc64-unknown-linux-stage-final.drv-0/build/./gcc/libgcc_s.so.1: ELF file data encoding not little-endian configure:2575: $? = 1 -- Summary: Error building libgomp shared Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: sparc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43194
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #6 from viriketo at gmail dot com 2009-12-23 15:34 --- Done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files
--- Comment #5 from viriketo at gmail dot com 2009-12-09 16:27 --- I added first the report for making a cross-compiler, and I later *added* that the same problem happens building a native compiler. I agree closing the issue because of other reasons, but not because I wrote it contradictory. I think I wrote that quite clear about the problem happening in the build of cross and native compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #4 from viriketo at gmail dot com 2009-12-09 16:46 --- Created an attachment (id=19267) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19267action=view) Fix for libmudflap + libstdc++v3 for gcc 4.4.2 In gcc 4.4.2, libstdc++v3 is also affected by the CPP probelm. I attach the fix for gcc 4.4.2 that fixes both libstdc++v3 and libmudflap builds, and I imagine, any target library build. -- viriketo at gmail dot com changed: What|Removed |Added Attachment #19226|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files
--- Comment #2 from viriketo at gmail dot com 2009-12-08 10:26 --- Sorry, I noticed that the libtsdc++ build does not help in this case, because it is build with -nostdlib, and the startfile objects are determined by the configure script. It is a special case of linking, not to be compared with that of libmudflap. We want libmudflap built without '-nostdlib', I understand. So, I vote somehow to get the target libraries libtool scripts to pass -Bxxx compile/link flags. That may be related to a bug in libtool, but I did some simple tests with a self-built libtool script (out of the gcc tree), and there -Bxxx were passed. I don't know the internals enough to understand the different behaviours of the gcc target libraries libtool and my copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files
--- Comment #3 from viriketo at gmail dot com 2009-12-08 21:28 --- I found the (proper?) way of getting -Bxxx flags to the target libraries, even if they use libtool: make FLAGS_FOR_TARGET Any -Bxxx in CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET gets ignored, but those in FLAGS_FOR_TARGET pass. Unless the gcc developers want CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET to handle -Bxxx passing it to the target linking commands, I imagine this can be closed as resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #3 from viriketo at gmail dot com 2009-12-08 23:07 --- I already sent the patch to the mailing list mentioned. I noticed this problem also affects gcc 4.4.2. The same patch can be applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libmudflap/42318] New: The newer libtool scripts break the build of libmudflap regarding the start files
Hello, in my build system I want to have the glibc in a different path, and I pass -B/myglibcpath/lib in CFLAGS_FOR_TARGET and LDFLAGS_FOR_TARGET in the make process. This flag was respected in the target libmudflap linking step of gcc 4.3.4, and therefore the usual crti.o and other startfiles needed for the shared library linking were found at the proper -B/myglibcpath/lib directory. In gcc 4.4.2, the libtool script no more passes the -Bxxx flags in LDFLAGS_FOR_TARGET or CFLAGS_FOR_TARGET to the linking process of libmudflap, and in my build, the startfiles are not found and so the build breaks. I think that this should be solved in the way the target libstdc++ is built, which works in gcc 4.3.4 and also in 4.4.2. I notice the relevant difference in the archive_cmd generated in the libtool script, that in libstdc++ it includes some predep_objs and some others, and therefore the linking command includes the absolute path to the crti.o and other startfiles files as linking objects. In libmudflap, no startfiles are passed, and they are expected to be in the gcc built-in and usual -B paths. I imagine that the difference between libstdc++ and libmudflap libtools is triggered by some m4 scripts included in the libstdc++ build, that are not included in the libmudflap build. Maybe lib-ld.m4, lib-link.m4, lib-prefix.m4 ? I don't know autoconf enough to understand this difference. I don't see in gcc 4.4.2 any other way of having the target glibc in a separate directory other than patching the configure scripts; I hope this can be solved and the mainline build system supports this again. -- Summary: The newer libtool scripts break the build of libmudflap regarding the start files Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug libmudflap/42318] The newer libtool scripts break the build of libmudflap regarding the start files
--- Comment #1 from viriketo at gmail dot com 2009-12-07 19:07 --- I add that this happens also in native builds (host=build=target). gcc 4.3.4's libtool did not trim -Bxxx out of the libmudflap linking command (maybe because of a quite old libtool). I wonder if the libstdc++ style of aclocal.m4 file can be used, because there looks like if there is a trick with acinclude.m4 and aclocal.m4 to use libtool, which I don't understand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42318
[Bug other/42280] libiberty configure script fails checking pid_t when without-headers
--- Comment #5 from viriketo at gmail dot com 2009-12-05 12:34 --- Sorry for not posting the full log before, but I noticed that the failing target is configure-target-libiberty. I don't understand how libiberty can be built for the target when building a cross compiler --without-headers, because it requires system libraries. Shouldn't target-libiberty be disabled under cross-compilation without headers? I see that under the same configure parameters, in 4.3.4, target-libiberty is not built (looking at build logs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
[Bug other/42280] libiberty configure script fails checking pid_t when without-headers
--- Comment #6 from viriketo at gmail dot com 2009-12-05 14:03 ---
Ok, I traced the problem down. The main change between 4.3.4 and 4.4.1 that
triggered the problem was the addition of 'zlib' in the core package (what I am
trying to build).
The configure script has the following logic around line 5370:
# Sometimes the tools are distributed with libiberty but with no other
# libraries. In that case, we don't want to build target-libiberty.
# Don't let libgcc imply libiberty either.
if test -n ${target_configdirs} ; then
libgcc=
others=
for i in `echo ${target_configdirs} | sed -e s/target-//g` ; do
if test $i = libgcc; then
libgcc=target-libgcc
elif test $i != libiberty ; then # OFFENDING CHECK
if test -r $srcdir/$i/configure ; then
others=yes;
break;
fi
fi
done
if test -z ${others} ; then
target_configdirs=$libgcc # This happens only if 'zlib' is not there - and
this line should be run in my use case.
fi
fi
So, I can't really propose a patch. What I did to get gcc 4.4.2 building is
remove the zlib directory after unpacking the core package.
I don't know the packaging procedure of gcc, but this concerns this procedure.
I don't know what status apply to the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
[Bug other/42280] libiberty configure script fails checking pid_t when without-headers
--- Comment #8 from viriketo at gmail dot com 2009-12-05 14:49 --- As I said in a previous comment, removing the 'zlib' subdirectory (not included in releases older than 4.4.2) made make all and make installl work perfectly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
[Bug c/42300] New: Having LIBRARY_PATH set but with null contents, makes gcc read ./specs
I think that a LIBRARY_PATH set, but without any contents (as done in shell with LIBRARY_PATH= ) will make gcc read the specs file from the directory '.'. Having no LIBRARY_PATH in the environment does not make gcc read ./specs. For example. this can break the build of a cross-compiler with g++, because the g++ is compiled with the build gcc after building the cross-gcc, which created a 'specs' file in the current directory (build/gcc). In this build, the built-in specs in the build gcc should be used, and not those of the cross compiler (./specs). This can be reproduced trying to make a g++ cross-compiler with the LIBRARY_PATH environment variable set but with a null string content. I could reproduce this with gcc 4.3.4 too, either a native or a cross compiler. If it is a feature, I think the LIBRARY_PATH section in the gcc manual should explain about this, because I would expect this behaviour only under LIBRARY_PATH=. -- Summary: Having LIBRARY_PATH set but with null contents, makes gcc read ./specs Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux or any target for a cross-compiler http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42300
[Bug libmudflap/42279] New: libmudflap checks with the wrong CPP for execinfo.h
Libmudflap receives the host CPP to test the headers with, instead of receiving the target CPP. I noticed it having a linux gnu system with glibc and targetting a uclibc linux. I will attach a patch with the fix I used. -- Summary: libmudflap checks with the wrong CPP for execinfo.h Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: armv5tel-unknown-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #1 from viriketo at gmail dot com 2009-12-04 18:44 --- Created an attachment (id=19226) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19226action=view) Fix the CPP needed by libmudflap when cross-compiling -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug other/42280] New: libiberty configure script fails checking pid_t when without-headers
Trying to build a gcc 4.4.2 for 'baremetal' targets, in my case for later libc building, I find that the libiberty configure script at some stage checks for some libc headers to be available. I'm calling the gcc main configure with --without-headers. The total flags are: --prefix=/nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static --with-ppl=/nix/store/kdsz815whid3giyi9ll3bshxdmp3jyyj-ppl-0.10.2 --with-cloog=/nix/store/zidphypb94508svrm4b2dxj9bhwpp2fr-cloog-ppl-0.15.4 --with-gmp=/nix/store/sli4r6plz8bkbizia8mr8p0rhxvrk06v-gmp-4.3.1 --with-mpfr=/nix/store/q5x2ajrskdj5bv2md78k5yqapdiy0sqg-mpfr-2.4.1 --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-languages=c --target=armv5tel-unknown-linux-uclibceabi --disable-libssp --disable-nls --without-headers --disable-threads --disable-libmudflap --disable-libgomp --disable-shared I could build gcc 4.3.4 perfectly with the options I was using. The concerning contents at the directory build/armv5tel-unknown-linux-uclibceabi/libiberty/config.log give: configure:5359: /tmp/nix-build-12l4vcfky0013w4gx5fpky81s4gb90gd-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static.drv-0/build/./gcc/xgcc -B/tmp/nix-build-12l4vcfky0013w4gx5fpky81s4gb90gd-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static.drv-0/build/./gcc/ -B/nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/bin/ -B/nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/lib/ -isystem /nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/include -isystem /nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/sys-include -c -B/lib -idirafter /include -Wl,-L/libconftest.c 5 conftest.c:41:19: error: stdio.h: No such file or directory conftest.c:43:24: error: sys/types.h: No such file or directory conftest.c:46:23: error: sys/stat.h: No such file or directory conftest.c:53:22: error: stdlib.h: No such file or directory conftest.c:58:22: error: memory.h: No such file or directory conftest.c:60:21: error: string.h: No such file or directory conftest.c:63:22: error: strings.h: No such file or directory conftest.c:66:23: error: inttypes.h: No such file or directory conftest.c:73:21: error: unistd.h: No such file or directory conftest.c: In function 'main': conftest.c:78: error: 'pid_t' undeclared (first use in this function) conftest.c:78: error: (Each undeclared identifier is reported only once conftest.c:78: error: for each function it appears in.) conftest.c:78: error: expected expression before ')' token configure:5365: $? = 1 -- Summary: libiberty configure script fails checking pid_t when without-headers Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: armv5tel-unknown-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
[Bug other/42280] libiberty configure script fails checking pid_t when without-headers
--- Comment #2 from viriketo at gmail dot com 2009-12-04 23:14 --- It should not use any standard headers. I don't expect this cross-gcc to build any executable. Only to compile code. Isn't this a usual stage bootstrapping? Then, when having a libc, with the help of 'ld' and libc objects, the gcc will be able to build executables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
[Bug other/42280] libiberty configure script fails checking pid_t when without-headers
--- Comment #4 from viriketo at gmail dot com 2009-12-04 23:20 --- I think I understand that libiberty must be compiled for the host, and not for the target. Then, 'xgcc' wants the system headers, to build the cross compiler, and not those of the target libc. In this case it would be my fault. I will investigate more. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
