Hello,
I've try to compilie binutils.
***
// At First
/usr/src/binutils-2.20/configure --enable-shared CFLAGS="-march=native -g -O3"
CXXFLAGS="-march=native -g -O3"
// Second
make
// After a time
libtool: link: (cd ".libs" && rm -f "libbfd.so" && ln -s "libbfd-2.20.so"
"libbfd.so")
libto
--- Additional Comments From ian at airs dot com 2009-11-11 06:48 ---
That part is never going to work with gold. It is asking the linker for the
default linker script, editing it, and passing it back to the linker. gold does
not have a default linker script to edit. Building glibc wit
--- Additional Comments From iwamatsu at nigauri dot org 2009-11-11 01:17
---
Subject: Re: `builddir-single/libiberty/pic/libiberty.a':
No such file or directory
Hi,
2009/11/11 nickc at redhat dot com :
>
> --- Additional Comments From nickc at redhat dot com 2009-11-10
--
What|Removed |Added
CC||rixed at free dot fr
http://sourceware.org/bugzilla/show_bug.cgi?id=10144
--- You are receiving this mail
--- Additional Comments From hjl dot tools at gmail dot com 2009-11-10
21:04 ---
You can try:
http://sourceware.org/ml/binutils/2009-11/msg00035.html
I will use it to enable gold in the next Linux binutils.
--
What|Removed |Added
---
gold is faster and a few things (e.g. llvm) have started to require it -- but
at the moment, it isn't
possible to build everything with gold (e.g. gold can't link glibc, building
VirtualBox with gold seems to
cause corrupted debug info, ...).
Distributions are starting to come up with hacks to
Trying to build glibc 2.11 with gold (after patching out configure.in's checks
for the expected ld
version) results in
gcc -nostdlib -nostartfiles -r -o
/usr/src/ark/BUILD/libc/build-x86_64-linux/elf/librtld.os '-Wl,-('
/usr/src/ark/BUILD/libc/build-x86_64-linux/elf/dl-allobjs.os
/usr/src/a
--- Additional Comments From chris at seberino dot org 2009-11-10 17:31
---
Subject: Re: Bug in objdump when disassembling raw
armv4t binaries
On Tue, Nov 10, 2009 at 10:32:26AM -, nickc at redhat dot com wrote:
> I am planning on applying the uploaded patch to address th
--- Additional Comments From giecrilj at stegny dot 2a dot pl 2009-11-10
16:14 ---
Subject: RE: The entry point is mainCRTStartup
That patch is right, thanks, except that that PE is rather surprising
because is not used as a target symbol within gcc docs. I cannot tell about
BeOS beca
--- Additional Comments From nickc at redhat dot com 2009-11-10 16:00
---
Hi Christopher,
The uploaded patch changes the documentation to read:
There are several ways to set the entry point. The linker will
set the entry point by trying each of the following methods in
orde
--- Additional Comments From nickc at redhat dot com 2009-11-10 15:58
---
Created an attachment (id=4379)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4379&action=view)
Amend linker documentation
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10865
--- You are rece
--- Additional Comments From nickc at redhat dot com 2009-11-10 15:41
---
Hi Yevgeniy,
It certainly does look like a binutils bug.
Are you able to repeat the test using a more modern version of gcc ? Say one
of the 4.x series ? (This is just a guess, but maybe there is a problem
--- Additional Comments From nickc at redhat dot com 2009-11-10 15:32
---
Hi Iwamatsu-san,
I am sorry, but this is a problem with the libiberty library which is part of
the gcc project, not the binutils project. You should submit your bug report
and proposed solution to the gcc bugzi
Hi Charles,
This error appeared after changing line 4894 from "push r2" to "push r2, r3"
Since that should change just a single bit in the generated code, I find this
to be
a most curious error.
I will be happy to run tests or provide files for you to test with.
Please could you try again u
as -asghlm=strongforth.lis -L --defsym dbgcode=1 strongforth.s -o strongforth.ostrongforth.s: Assembler messages:strongforth.s:4011: Error: unknown pseudo-op: `.pool159'strongforth.s:4016: Error: junk at end of line, first unrecognized character is `c'strongforth.s:4016: Internal error!Assert
--- Additional Comments From nickc at redhat dot com 2009-11-10 10:32
---
Hi Chris,
I am planning on applying the uploaded patch to address this issue, but I
would like your feedback on the new behaviour. With the patch applied your
testcase will disassemble as:
<.text>:
--- Additional Comments From nickc at redhat dot com 2009-11-10 10:29
---
Created an attachment (id=4377)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4377&action=view)
Add UNPREDICTABLE warning for insns which use Addressing Mode 3 and P == 0 and
W == 1
--
http://sourcewa
--
What|Removed |Added
CC||mnowak at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=10238
--- You are receiving this
18 matches
Mail list logo
