Hi Jori,
We encountered a linking error in 11.1 and 11.2 of the ARM GNU Toolchain.
If this is a toolchain produced by ARM, then you really need to contact them,
not us. If you can reproduce the problem using the GNU Binutils sources
directly, then please feel free to report the bug here:
ht
On Mon, Feb 28, 2022 at 6:43 AM Nick Clifton wrote:
> Hi John,
>
> > If you need some exe/object files, traces, etc. let me know and I will
> try to supply.
> Yes please. If you can give me an x86_64 version of the failing
> executable I can try examining it to see what is going wrong.
> Is ther
Hi John,
If you need some exe/object files, traces, etc. let me know and I will try to
supply.
Yes please. If you can give me an x86_64 version of the failing executable I
can try examining it to see what is going wrong.
Is there any chance that you could provide a test case that only uses
On Thu, Feb 17, 2022 at 3:54 AM Nick Clifton wrote:
> Hi John,
>
> > It appears that LD in binutils versions after 2.35 is producing segfault
> executables with Free Pascal 2.6.4. You cannot build a working HelloWorld.
>
> Please could you file a bug report about this issue using the binutils
>
Hi John,
It appears that LD in binutils versions after 2.35 is producing segfault
executables with Free Pascal 2.6.4. You cannot build a working HelloWorld.
Please could you file a bug report about this issue using the binutils
bugzilla system:
https://sourceware.org/bugzilla/enter_bug.cg
On Fri, Jan 24, 2020 at 03:34:45PM +1100, john.adri...@bigpond.com wrote:
[on trying to use a symbol in a fill expression]
> arm-none-eabi/bin/ld.exe: bfd_link_hash_lookup failed: no error (It's the
> "no error" part that I like the most!)
Yes, that is silly. I'm going to commit the following to
On Thu, Aug 01, 2019 at 03:18:16PM -0400, Ryan Lagasse wrote:
> /home/user/dir/dir/br_extern/output/dir/host/opt/ext-toolchain/bin/../lib/gc
> c/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: BFD
> (Sourcery CodeBench Lite 2012.09-62) 2.23.51.20120829 internal error,
> aborting at
>
On Sun, Feb 12, 2017 at 02:08:30AM +, Peter Johnson wrote:
> https://coldplace.net/basm.o
How was this file made? It has an invalid symbol table.
[ 3] .symtab SYMTAB 0001f0 a8 18
4 6 8
sh_info above says the first global symbol is at index
On Tue, Jan 17, 2017 at 6:56 AM, Pavel Shishpor
wrote:
> Thanks a lot for the answer: it put me on the right track. The
> '-ffunction-sections' option works OK on toy examples though GNU linker
> crashed when I tried the following on real-life object files compiled with
> -ffunction-sections and -
Thanks a lot for the answer: it put me on the right track. The
'-ffunction-sections' option works OK on toy examples though GNU linker
crashed when I tried the following on real-life object files compiled with
-ffunction-sections and -fdata-sections options enabled:
for i in $object_files_original
On 01/11/2017 01:49 AM, Pavel Shishpor wrote:
Could please someone advice is it a bug or a feature when we get both
bodies of the functions with the same name in the executable once
multiple symbol definitions are allowed? Here is the example showing the
behavior:
The only thing that the --allo
Hi redfish,
> $ touch foo.dat
> $ /usr/bin/ld -r -b binary -o /tmp/foo.o foo.dat
> Segmentation fault (core dumped)
Ah - snafu - fixed by this patch.
Cheers
Nick
bfd/ChangeLog
2016-08-23 Nick Clifton
* elf32-arm.c (elf32_arm_count_additional_relocs): Return zero if
there i
Hi Igor,
$ ld -iqwerty
ld: bad -rpath option
Thanks very much for reporting this problem. I have checked in the
patch below to fix the bug. In the future though, please could you use
the binutils bugzilla system to report bugs: https://sourceware.org/bugzilla
Cheers
Nick
ld/ChangeLog
On Wednesday 24 of August 2011, Ian Lance Taylor wrote:
> Arkadiusz Miskiewicz writes:
> > Linux x86_64, 64 bit userspace
> >
> > binutils 2.21.53.0.2
> >
> > bfd works fine
> > $ ld.bfd -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc
> >
> > but gold fails
> > $ ld.gold -shared -o ulogd_BASE.so u
Arkadiusz Miskiewicz writes:
> Linux x86_64, 64 bit userspace
>
> binutils 2.21.53.0.2
>
> bfd works fine
> $ ld.bfd -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc
>
> but gold fails
> $ ld.gold -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc
> ld.gold: warning: skipping incompatible /usr/lib/libc.so
On Sat, Apr 30, 2011 at 6:13 PM, H.J. Lu wrote:
> On Sat, Apr 30, 2011 at 4:57 PM, Alan Modra wrote:
>> On Fri, Apr 29, 2011 at 05:07:33PM -0700, Roland McGrath wrote:
>>> I am seeing a strange thing. The (BFD) linker spuriously generates .plt
>>> and .rela.plt sections (both empty) for a link t
On Sat, Apr 30, 2011 at 4:57 PM, Alan Modra wrote:
> On Fri, Apr 29, 2011 at 05:07:33PM -0700, Roland McGrath wrote:
>> I am seeing a strange thing. The (BFD) linker spuriously generates .plt
>> and .rela.plt sections (both empty) for a link that has no need for them.
>> It's reproduced with a tr
On Fri, Apr 29, 2011 at 05:07:33PM -0700, Roland McGrath wrote:
> I am seeing a strange thing. The (BFD) linker spuriously generates .plt
> and .rela.plt sections (both empty) for a link that has no need for them.
> It's reproduced with a trivial example, and seen on today's binutils trunk.
> Gold
On Sat, 18 Dec 2010, Peter Eisentraut wrote:
> This works, in fact, but the option -rdynamic is not documented. I
> understand that GNU ld supports a whole host of legacy and compatibility
> options, but in case you don't want to document it, could you point out
> what the canonical option name i
Hi Prashant,
gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o
ld-new ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o
ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o eelf32my_target.o
../bfd/libbfd.la ../libiberty/libiberty.a -lz
../bfd/lib
On Mon, Dec 07, 2009 at 10:30:15AM +0100, Adrien Demarez wrote:
> I experience an ld segfault when trying to compile QT4.6 in
> OpenEmbedded/Angstrom for the PPC platform (MPC8313 more precisely). The
> following patch (against the CVS version) solves this : after having a
> look at the core fi
Hi,
2009/12/14 xxcv :
> ccache x86_64-w64-mingw32-gcc -m32 -o lua.exe -s lua.o lua51.dll -lm
> collect2: ld terminated with signal 11 [Segmentation fault]
> GNU ld (GNU Binutils) 2.20.51.20091214
Could you disable ccache on your build (might be a ccache bug)?
--
Héctor Orón
"Our Sun unleashe
On Mon, Dec 07, 2009 at 10:30:15AM +0100, Adrien Demarez wrote:
> Hello,
>
> I experience an ld segfault when trying to compile QT4.6 in
> OpenEmbedded/Angstrom for the PPC platform (MPC8313 more precisely). The
> following patch (against the CVS version) solves this : after having a
> look at
Hi VIJAYENDRA,
#0 htab_traverse (htab=0x0, callback=0x8098370 ,
I have seen this sort of thing before. It usually happens because the
linker has been given an input file which is not the same type as the
output file it has been asked to generate. Eg because main.o is not a
mips-elf object
version.
Regards
Vijayendra Suman
--- Original Message ---Sender : Nick CliftonDate : Sep 23, 2009 18:03 (GMT+09:00)Title : Re: Ld - 2.17.90 patch level 2.247 elfxx-mips.cHi VIJAYENDRA,
> After applying the patch for 2.247 of elfxx-mips.c,
> when i compile i get segfault
Ple
Hi VIJAYENDRA,
After applying the patch for 2.247 of elfxx-mips.c,
> when i compile i get segfault
Please could you try using the latest version of the linker (ie one
built from the head of the mainline binutils cvs sources). If the
problem still exists, please could you open a bug report
Alexander Beregalov writes:
> 2009/3/17 Andreas Schwab :
>> Could you please try this patch?
>>
>> Andreas.
>>
>> 2009-03-17 Andreas Schwab
>>
>> * elf32-hppa.c (final_link_relocate): Cast bfd_vma value to long
>> for format string.
>>
> It works, thanks!
Thanks for testing.
I
2009/3/17 Andreas Schwab :
> Alexander Beregalov writes:
>
>> #0 strlen (str=0xc84 ) at strlen.c:64
>> #1 0x407b7530 in _IO_vfprintf_internal (s=0xfb1487a0,
>> format=0xfb147d80 "arch/parisc/kernel/built-in.o(.text+0x%lx):
>> cannot reach %s, recompile with -ffunction-sections", ap=0xfb147d0
Alexander Beregalov writes:
> #0 strlen (str=0xc84 ) at strlen.c:64
> #1 0x407b7530 in _IO_vfprintf_internal (s=0xfb1487a0,
> format=0xfb147d80 "arch/parisc/kernel/built-in.o(.text+0x%lx):
> cannot reach %s, recompile with -ffunction-sections", ap=0xfb147d0c)
> at vfprintf.c:1581
> #2
Hi Johan,
The attached patches correct an issue that exists in ld when the object
code format is TI COFF.
Thanks you very much for submitting this patch. I have checked it into
the binutils sources along with these changelog entries.
Cheers
Nick
bfd/ChangeLog
2008-12-23 Johan Olmutz Ni
Hi Søren,
Hi I get the following error during transformation of a binary files into a
text-segment.
Not quite sure what you mean here. Are you trying to convert a binary
file into an object file so that you can include it in a larger program
? (In which case it would probably be a data sec
Hi Chris,
This turns out to be convenient in cases where one's build system
defaults to "ld --fatal-warning" but occasionally one would like to
override it. It's also parallel to existing gcc conventions for setting
and unsetting options. See attached diff to ld/lexsup.c; it's against
2.17
Hi Ashley,
I'm having some trouble using the linker... I am using V4.1.2 as part of
the WinAVR package.
Which version of the linker does this include ? If it is earlier then v2.18
please try downloading the current binutils sources and building a new linker.
If that does not solve the
Hi Michiel,
ld does not replace alias by symbol when import library has .lib
extension and output is a .dll (-shared). It does if import library has
.a extension, and also if output is a .exe.
Please could you file a bug report on this and include a simple test case to
reproduce the problem
Hi Constantine,
First of all, excuse me if i'm asking a naive question. I'm a complete
noob at using linker scripts (and generally ld), so please give me a
helping hand.
Certainly, although you are treading in a dark and mysterious region of
programming. I would suggest that you read up on
Hi Nick,
>> It happens to me under Ubuntu 7.04 and openSUSE 10.2 with the GNU
>> binutils and Wine versions supplied by these distros.
>
> Can you please tell us which versions these are ?
Sure, according to Ubuntu the versions are:
wine = 0.9.36~winehq0~ubuntu~7.04.1 (feisty)
binutils = 2.17.20
Hi Benjamin,
First excuse me, if this is the wrong place to report this,
No this is the right place. If you want to, you could also submit a bug
report at:
http://sourceware.org/bugzilla
but AFAIK ld should not crash, no matter what I try to link.
True.
It happens to me under Ubuntu
Hi Daniel,
strata:/home/dr2867/c/modules 1026 $$$ ->as --version
GNU assembler 2.15 [FreeBSD] 2004-05-23
This is an old version of the assembler.
strata:/home/dr2867/c/modules 1028 $$$ ->ld --version
GNU ld version 2.15 [FreeBSD] 2004-05-23
And an old version of the linker. We are at rele
Hi Ilya,
I am getting the following error when building an application for avr
platform (atmega1281 MCU, to be specific)
Please could you check to see if this problem still happens with a
linker built from the current mainline CVS binutils sources. If it does
then please could you open a bu
Hi Will,
Is this a known error,
No.
anything I can do to work round it?
Maybe, but without more information it is hard to say. Try generating a
map file (-M option to the linker). There should be an more informative
error message put into this file which might suggest a workaround.
S
Nick Clifton wrote:
Hi Doug,
.debug_* sections of the same name aren't getting merged in the
executable.
Try looking at the linker script that is being used. You may need to
add explicit entries for the debug sections.
Cheers
Nick
Thanks, that was a useful suggestion that got me ou
Hi Doug,
.debug_* sections of the same name aren't getting merged in the
executable.
Try looking at the linker script that is being used. You may need to
add explicit entries for the debug sections.
Cheers
Nick
___
bug-binutils mailing list
Dennis Heuer <[EMAIL PROTECTED]> writes:
> Today I installed a new i386 linux system from source with linux 2.6.16,
> gcc 4.1.0, glibc 2.4, and binutils 2.16. The problem I have is that ld
> refuses to detect libraries at other locations than /lib and /usr/lib
> though ld.so.conf and (LD_)LIBRARY_
On Sun, Apr 30, 2006 at 01:04:44PM -0400, Tom wrote:
> binutils: 2.16.1cvs20060117
> gcc: 4.0.3
>
> http://www.cygwin.com/bugzilla/show_bug.cgi?id=1025 seems to be very
> similar, but it was patched months ago according to the comments.
It was patched on mainline, not on the 2.16 branch.
--
Ala
On Mon, Jan 30, 2006 at 01:09:56AM +1100, John Pye wrote:
> > /usr/bin/ld: BFD 2.15.94.0.2.2 20041220 internal error, aborting at
> > ../../bfd/cache.c line 495 in bfd_cache_lookup_worker
> >
> > /usr/bin/ld: Please report this bug.
FYI, this abort is no longer present in current versions. It use
On Thu, 2005-12-22 at 10:25, John S. Worley wrote:
> ld: .data has both ordered and unordered sections
> ld: find link failed: Bad value
You might try using FSF binutils mainline, to see if perhaps the problem
is already fixed.
Current binutils mainline will emit a more helpful message, which giv
On Wed, Nov 02, 2005 at 06:01:03PM +0100, Jakub Jermar wrote:
> ld (from binutils 2.16) on mipsel doesn't warn about
> undefined symbols with elf32-little and binary output
> formats (and possibly others).
>
> When the output format is elf32-tradlittlemips, undefined
> symbols are reported as e
On Tue, Oct 11, 2005 at 07:27:45PM +0200, Philippe Biondi wrote:
> On Mon, 10 Oct 2005, Alan Modra wrote:
>
> >On Sun, Oct 09, 2005 at 05:28:15PM +0200, Philippe Biondi wrote:
> >>but I think these two linker scripts should be equivalent.
> >
> >No, you haven't specified where .got should go (*).
On Mon, 10 Oct 2005, Alan Modra wrote:
On Sun, Oct 09, 2005 at 05:28:15PM +0200, Philippe Biondi wrote:
but I think these two linker scripts should be equivalent.
No, you haven't specified where .got should go (*). ld is free to place
unspecified sections where it likes.
*) Which is quite f
On Sun, Oct 09, 2005 at 05:28:15PM +0200, Philippe Biondi wrote:
> but I think these two linker scripts should be equivalent.
No, you haven't specified where .got should go (*). ld is free to place
unspecified sections where it likes.
*) Which is quite foolish, given that you defined a symbol th
Hi Jakub,
the kernel image is linked together correctly (line is present) or the
.mapped section overwrites the .unmapped section (line is not present).
When you say that it overwrites are you referring to the load-time
address (LMA) or the run-time address (VMA) or both ?
Is there anythin
The linker script I sent you yesterday is missing the magical line.
The one below is ok.
jj
Hello binutils people,
my team discovered a strange problem with the linker script which I attach to
this email.
Depending on the presence of the line containing:
LONG(0xdeadbeaf);
the ker
Hi Zhigang,
Hmm. I am basically using the same or very similar sources as you.
All the sources are from checkouts from the various CVS repositories on
8 Sept 2005. The versions are binutils v2.16.91, gcc v4.1.0, and newlib
v1.13.0. I also configured my toolchain in the same way as you,
a
Hi Nick，
I am sorry for sent the big attachment to everyone in this
mailist. I do will not do that thing from now on.
Beacuse I can't access the cvs(behind a firewire) server.
I just download the
binutils-050909 , gcc-4.0-20050901 and newlib-1.13.0. And I rebuild binutils and
gc
Hi Zhigang,
sorry i forgot to attach the file. Now attach the tar ball.
Unfortunately you sent this huge attachment to the entire binutils
mailing list, not just me. In the future please try not to do this. If
you cannot create a small test case then please either just send the
large test
Hi Nick,
Tanks for you reply so soonly. I had already download the
latest snapshot(binutils-050907), and the problem has not resolve
yet.I try to make the case smaller, but i failed. As when I make some
modification ,the problem will not exist any more. I have to send you
a little big tes
Hi Zhigang,
/home/zhigang/0808/pattern_install/lib/extras.o
0x8090bc4d
piofree_handle --Please see here, the
address is not correct aligned
.comm piofree_handle,4,4(the alignment is right)
This does
On Fri, Jul 15, 2005 at 03:39:50PM -0400, David Lawless wrote:
> Is this the correct approach? Or am I missing some important
> detail, such as not making certain symbols LOCAL? Or am I
> on entirely the wrong path for obtain my objective?
Local symbols are not accessible from outside of the fil
Hi Alexander,
Trying to build arm-elf (from sparc-solaris) I got the following
error:
LIB_PATH='' /bin/sh ../../binutils-2.16.1/ld/genscripts.sh
../../binutils-2.16.1/ld /home/sw/ask/gnuarm/lib
"/home/sw/ask/gnuarm" sparc-sun-solaris2.8 arm-unknown-elf arm-elf
"armelf" "/usr/local/lib /lib /usr
Hi Steve,
This is request to binutils to fix -wrap to work properly with all
symbol references.
This would be a useful feature but unless you want to implement it
yourself I think that it might be quite a long time before somebody
decides to have a go at it.
I am sorry to be so pessimistic, bu
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> > 1) It's traditional Unix behaviour, so changing it will break some
> >programs.
>
> Any example ?
I don't have any specific examples, no.
> > 2) It is more efficient, as the linker can just walk through an
> >archive's symbol table, include al
On Mon, 7 Mar 2005, Ian Lance Taylor wrote:
> Nilmoni Deb <[EMAIL PROTECTED]> writes:
>
> > > This is correct and documented behaviour. All Unix linkers behave
> > > this way.
> >
> > In other words, its a feature, not a bug. It seems that the ICC (intel
> > cc) on linux does not have this featu
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> > This is correct and documented behaviour. All Unix linkers behave
> > this way.
>
> In other words, its a feature, not a bug. It seems that the ICC (intel
> cc) on linux does not have this feature.
Really? I haven't tried it myself.
> Just wondering
On Mon, 7 Mar 2005, Ian Lance Taylor wrote:
> Nilmoni Deb <[EMAIL PROTECTED]> writes:
>
> > Lets say I am running the following command
> >
> > gcc z.o -lX -lY -o z
> >
> > and libX.a depends on a function that is defined in libY.a then the order
> > of linking appears to be important. While
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> Lets say I am running the following command
>
> gcc z.o -lX -lY -o z
>
> and libX.a depends on a function that is defined in libY.a then the order
> of linking appears to be important. While the previous command works, the
> next one (with order re
65 matches
Mail list logo
