[Bug binutils/4712] BFD: section .data1/.bss can't be allocated in segment 0

2007-06-29 Thread amodra at bigpond dot net dot au
--- Additional Comments From amodra at bigpond dot net dot au 2007-06-30 01:12 --- Neither of the attached files have correct program headers. For libFS.so, Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0

[Bug ld/4715] gld fails to link Solaris 10/x86 libnsl.so

2007-06-29 Thread ro at TechFak dot Uni-Bielefeld dot DE
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE 2007-06-29 19:04 --- It turns out that gld 2.17.50 (the current CVS version) seems to work. I'm currently running a GCC bootstrap with it. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4715 --- You are rece

[Bug ld/4715] New: gld fails to link Solaris 10/x86 libnsl.so

2007-06-29 Thread ro at TechFak dot Uni-Bielefeld dot DE
Consider the following trivial test program: int main (void) { gethostbyname(); } Compiling and linking it with gcc 4.3.0 20070618 configured with gas and gld 2.17 fails: ./collect2 -V -m elf_i386 -Y P,/usr/ccs/lib:/usr/lib -Qy -o ghn /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o ./cr

[Bug gas/4713] New: obj-elf.c fails to compile on IRIX 5.3

2007-06-29 Thread ro at TechFak dot Uni-Bielefeld dot DE
I tried to build binutils from CVS as of 20070629, but compilation failed: /vol/gcc-3.4/bin/gcc -DHAVE_CONFIG_H -I. -I/vol/gnu/src/binutils/binutils-dist/gas -I. -D_GNU_SOURCE -I. -I/vol/gnu/src/binutils/binutils-dist/gas -I../bfd -I/vol/gnu/src/binutils/binutils-dist/gas/config -I/vol/gnu/src

[Bug binutils/4712] BFD: section .data1/.bss can't be allocated in segment 0

2007-06-29 Thread pluto at agmk dot net
--- Additional Comments From pluto at agmk dot net 2007-06-29 15:51 --- native solaris stripper works fine. $ strip -V strip: Software Generation Utilities (SGU) Solaris-ELF (4.0) $ uname -a SunOS hermes 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-1500 -- http://sourceware.org

[Bug binutils/4712] BFD: section .data1/.bss can't be allocated in segment 0

2007-06-29 Thread pluto at agmk dot net
--- Additional Comments From pluto at agmk dot net 2007-06-29 15:48 --- Created an attachment (id=1905) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1905&action=view) testcase #2 -- http://sourceware.org/bugzilla/show_bug.cgi?id=4712 --- You are receiving this mail bec

[Bug binutils/4712] BFD: section .data1/.bss can't be allocated in segment 0

2007-06-29 Thread pluto at agmk dot net
--- Additional Comments From pluto at agmk dot net 2007-06-29 15:48 --- Created an attachment (id=1904) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1904&action=view) testcase #1 -- http://sourceware.org/bugzilla/show_bug.cgi?id=4712 --- You are receiving this mail bec

[Bug binutils/4712] New: BFD: section .data1/.bss can't be allocated in segment 0

2007-06-29 Thread pluto at agmk dot net
after switching from 2.17.50.0.12 to 2.17.50.0.17 i'm observing assertion failures during stripping native solaris libs. $ sparc-sun-solaris2.9-strip libFS.so.5 BFD: BFD (Linux/GNU Binutils) 2.17.50.0.17.20070615 assertion fail elf.c:6234 BFD: st53IDU9: section `.data1' can't be allocated in segme

[Bug binutils/4697] `as' compile-time hog (-ffunction-sections negative impact)

2007-06-29 Thread pluto at agmk dot net
--- Additional Comments From pluto at agmk dot net 2007-06-29 15:37 --- (In reply to comment #3) > Have you tried binutils-2.17.50.0.17? .17 works fine, but i'm observing new assertion failures in .17 on sparc-sun-solaris2.9. i'll fill it as new PR. -- http://sourceware.org/bugzilla/

Re: Is there a "GNU Assembler General Public License"?

2007-06-29 Thread Nick Clifton
Hi Erich, we have found a reference to a license called "GNU Assembler General Public License" in the file: \binutils-2.16.1\gas\flonum-mult.c (see below) We suppose that this is just a misspelling of the " GNU General Public License", since we have not found a GNU Assembler General Public Li

[Bug binutils/4709] New: improper index in dofloat() : i386-dis.c

2007-06-29 Thread ht at inter7 dot jp
i386-dis.c now uses MAX_OPERANDS but the operand index (op_ad) in dofloat() is not updated yet. I think it's better to fix although I don't find visible effects. Index: i386-dis.c === RCS file: /cvs/src/src/opcodes/i386-dis.c,v retri