[Bug binutils/13652] non elf core file whose whose size is greater than zero && u.u_dsize == 0 && u.u_ssize == 0 are being recognized as trad-core
http://sourceware.org/bugzilla/show_bug.cgi?id=13652 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Summary|non elf core file whose |non elf core file whose |whose size is greater than |whose size is greater than |zero && u.u_dsize == 0 && |zero && u.u_dsize == 0 && |u.u_ssize == 0 are being|u.u_ssize == 0 are being |recognized as tad-core |recognized as trad-core --- Comment #3 from Alan Modra 2012-02-15 09:20:33 UTC --- I don't believe there is a "magic number". See http://modman.unixdev.net/?sektion=5&page=core&manpath=4.2BSD -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13683] usage tracking by --gc-sections ignores a --defsym mapping
http://sourceware.org/bugzilla/show_bug.cgi?id=13683 --- Comment #7 from Nick Clifton 2012-02-15 09:57:43 UTC --- Hi Alan, > can you just run lang_do_assignments before lang_gc_sections instead? I tried that, but could not find a way to make it work. If you run it with lang_first_phase_enum it does not recompute the defsym assignments. If you run it with any other enum it fails the "output section size must be non-zero" assertion in lamg_size_sections_1. I agree however that re-invoking lang_do_assignments would be a better way to fix the problem. I will investigate some more and see if I can persuade it to work. Cheers Nick -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4933] windres does not escape path with spaces in them
http://sourceware.org/bugzilla/show_bug.cgi?id=4933 Kai Tietz changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #5 from Kai Tietz 2012-02-15 11:59:49 UTC --- As this issue is pretty old and I expect reporter won't reply anymore, I will close this bug. If issue still exists, please open an new report for it. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6449] objdump -S and DOS-style line-endings
http://sourceware.org/bugzilla/show_bug.cgi?id=6449 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at redhat dot com Resolution||FIXED --- Comment #2 from Kai Tietz 2012-02-15 12:13:13 UTC --- It was added to sysdep.h (via including include/binary-io.h) and objdump.c in binutils also specifies O_BINARY for open. So bug is fixed. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13683] usage tracking by --gc-sections ignores a --defsym mapping
http://sourceware.org/bugzilla/show_bug.cgi?id=13683 --- Comment #8 from Don Kinzer 2012-02-15 16:48:20 UTC --- I back-ported the patch to ld 2.19.1. In doing so, I had to modify the patch slightly because that version of the source doesn't have the function exp_defsym(). I created a similar function and changed the yacc grammar action to invoke it when the --defsym option is seen. In testing, I can see that a defsym_node structure is created and put on the defsym_list list. Further, that single node is processed when ldexp_rerun_defsyms() is called and the two conditions therein are true allowing exp_fold_tree() to be called. This all suggests that I've patched my version correctly but the resulting executable image is the same as before: 00c8 : c8:9b df rcall.-202; 0x0 <__vectors> ca:ff cf rjmp.-2 ; 0xca If it works on your version of ld then it appears that there may be other changes required for v2.19.1. Regards, Don Kinzer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13683] usage tracking by --gc-sections ignores a --defsym mapping
http://sourceware.org/bugzilla/show_bug.cgi?id=13683 --- Comment #9 from Alan Modra 2012-02-16 02:00:09 UTC --- Created attachment 6215 --> http://sourceware.org/bugzilla/attachment.cgi?id=6215 early lang_do_assignments This also seems to work. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
binutils-2.22/intl/configure does not set INCINTL in config.intl when --with-libintl-prefix specified
There is a configuration parameter to influence how INCINTL gets set in
config.intl.
--with-libintl-prefix[=DIR] search for libintl in DIR/include and
DIR/lib
However, the configured value for INCINTL is not written to config.intl
in binutils-2.22/intl/configure.
I am compiling on mingw-w64 on Windows 64-bit using libiconv and libintl
built from gettext-0.18.1.
Here is the configure command line to reproduce the behavior:
binutils-2.22
./configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --prefix=$(cd ../install && pwd)
--disable-shared --enable-static
--enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --enable-ld=yes
--enable-cloog-backend=isl --with-gmp=$(cd ../install && pwd)
--with-mpc=$(cd ../install && pwd) --with-mpfr=$(cd ../install && pwd)
--with-ppl=$(cd ../install && pwd) --with-cloog=$(cd ../install && pwd)
--with-libiconv-prefix=$(cd ../install && pwd)
--with-libintl-prefix=$(cd ../install && pwd)
binutils-2.22/intl
./configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --prefix=$(cd ../../install && pwd)
--with-libiconv-prefix=$(cd ../../install && pwd)
--with-libintl-prefix=$(cd ../../install && pwd)
The include library is found in $CPPFLAGS so INCINTL is not written to
config.intl. binutils-2.22/bfd then can't find libintl.h.
binutils-2.22/intl/configure
if test "X$additional_includedir" != "X"; then
if test "X$additional_includedir" != "X/usr/include"; then
haveit=
if test "X$additional_includedir" =
"X/usr/local/include"; then
if test -n "$GCC"; then
case $host_os in
linux*) haveit=yes;;
esac
fi
fi
if test -z "$haveit"; then
// Changed line 6021
- for x in $CPPFLAGS $INCINTL; do
// to
+ for x in $INCINTL; do
acl_save_prefix="$prefix"
prefix="$acl_final_prefix"
In the attached file, the other fixes to get binutils-2.22 to compile on
mingw-w64 are:
(1) Same fix as https://trac.macports.org/ticket/26537 applied to
binutils-2.22/gold/gold.h
+#ifdef setlocale
+// Someone in libintl world decided it was a good idea to define a
"setlocale" macro.
+#undef setlocale
+#endif
(2) http://sourceware.org/bugzilla/show_bug.cgi?id=13292
(3) binutils-2.22/configure checks for the exact version of cloog
0.16.x. I have 0.17.0. Is changing this test from "!= 16" to ">= 16" safe?
(4) binutils-2.22/gold/descriptors.cc - compiler warning about 'fd'
being an unused parameter treated as an error.
static inline void
set_close_on_exec(int fd)
{
// Mingw does not define F_SETFD.
#ifdef F_SETFD
fcntl(fd, F_SETFD, FD_CLOEXEC);
#else
(void)fd;
#endif
}
I'm also getting "narrowing conversion" warnings (treated as errors)
trying to compile binutils-2.22/gold using gcc 4.7.
I found this config file which looks like one way to get rid of the
warnings.
http://svn.openttd.org/trunk/config.lib
if [ $cc_version -ge 43 ]; then
# Use gnu++0x mode so static_assert() is available.
# Don't use c++0x, it breaks mingw (with gcc 4.4.0).
cxxflags="$cxxflags -std=gnu++0x"
fi
if [ $cc_version -ge 47 ]; then
# Disable -Wnarrowing which gives many warnings, such as:
# warning: narrowing conversion of '...' from 'unsigned
int' to 'int' inside { } [-Wnarrowing]
# They are valid according to the C++ standard, but useless.
cxxflags="$cxxflags -Wno-narrowing"
# Disable bogus 'attempt to free a non-heap object' warning
flags="$flags -Wno-free-nonheap-object"
fi
x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I. -I./../include
-I./../elfcpp -DLOCALEDIR="\"/c/work/
sources/install/share/locale\""
-DBINDIR="\"/c/work/sources/install/bin\"" -DTOOLBINDIR="\"/c/work/s
ources/install/x86_64-w64-mingw32/bin\""
-I/c/work/sources/install/include -W -Wall-Wno-format
-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-frandom-seed=dwarf_reader.o -g -O2 -MT dwarf_rea
der.o -MD -MP -MF .deps/dwarf_reader.Tpo -c -o dwarf_reader.o
dwarf_reader.cc
dwarf_reader.cc: In instantiation of 'const unsigned char*
gold::Sized_dwarf_line_infoian>::read_lines(const unsigned char*, unsigned int) [with int size =
32; bool big_endian = false]':
dwarf_reader.cc:925:7: required from here
dwarf_reader.cc:495:56: error: narrowing conversion of
'lsm.gold::LineStateMachine::address' from 'u
int64_t {aka long long unsigned int}' to 'off_t {aka long long int}'
inside { } is ill-formed in C++
11 [-Werror=narrowing]
dwarf_reader.cc:495:56: error: narrowing conversion of
'lsm.gold::LineStateMachine::file_num' from '
int' to 'unsigned int' inside { } is ill
[Bug binutils/13355] elf32-rx.c: 2 * bad comparison
http://sourceware.org/bugzilla/show_bug.cgi?id=13355 --- Comment #1 from cvs-commit at gcc dot gnu.org 2012-02-16 07:40:33 UTC --- CVSROOT:/cvs/src Module name:src Changes by:amo...@sourceware.org2012-02-16 07:40:23 Modified files: bfd: ChangeLog elf32-rx.c Log message: PR binutils/13355 * elf32-rx.c (elf32_rx_relax_section): Correct width check. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5608&r2=1.5609 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-rx.c.diff?cvsroot=src&r1=1.15&r2=1.16 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/13355] elf32-rx.c: 2 * bad comparison
http://sourceware.org/bugzilla/show_bug.cgi?id=13355 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution||FIXED --- Comment #2 from Alan Modra 2012-02-16 07:42:27 UTC --- Patch committed, thanks! -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
