On Tue, Nov 23, 2010 at 08:28:11AM +0100, Roger Jeurninck wrote:
> this linker version is part of a 3rd party development suite, so for myself
> it's not easy to only update the linker.
In that case we can't help you much more..
> Can you remember if there was some kind of reproduction scenario a
Hi Alan,
this linker version is part of a 3rd party development suite, so for myself
it's not easy to only update the linker.
Can you remember if there was some kind of reproduction scenario at that
time?
greetings,
Roger
2010/11/22 Alan Modra
> On Mon, Nov 22, 2010 at 02:34:29PM +0100, Roger
On Mon, Nov 22, 2010 at 02:34:29PM +0100, Roger Jeurninck wrote:
> the version which we use is 2.17.
That's over 4 years old! We are about to release 2.21. I recall
fixing one uninitialised memory bug in that time. There were likely
others too.
--
Alan Modra
Australia Development Lab, IBM
__
Hi Alan,
the version which we use is 2.17.
greetings,
Roger
2010/11/22 Alan Modra
> On Mon, Nov 22, 2010 at 01:54:58PM +0100, Roger Jeurninck wrote:
> > I'm running into build behaviour which might be caused by a
> > non-deterministic GNU linker?!
>
> This could be caused by ld reading uninit
On Mon, Nov 22, 2010 at 01:54:58PM +0100, Roger Jeurninck wrote:
> I'm running into build behaviour which might be caused by a
> non-deterministic GNU linker?!
This could be caused by ld reading uninitialised memory. A tool like
valgrind is useful in tracking down such things. What version of GN
Hi,
I'm running into build behaviour which might be caused by a
non-deterministic GNU linker?! As this is quiet unlikely I hope you can
support me in reducing this issue so I can find the real root cause.
Thanks,
Roger
--
What is the issue?
at the c
