https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #12 from winter-...@bfw-online.de ---
> It has been done. :-)
Thanks a lot ;)
So downstream [1] is asking for an inclusion into the 2.26 branch. Considering
the regression was first visible in 2.26 it might be reasonable to
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #9 from winter-...@bfw-online.de ---
It seems that symbols absolute sections should not be relocated. My testing on
SCO yielded positive results. The friendly djgpp developers confirmed it works
for them, too:
http
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
winter-...@bfw-online.de changed:
What|Removed |Added
Attachment #8981|0 |1
is obsolete
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #7 from winter-...@bfw-online.de ---
For further discussion from DJGPP developers also see their mailing list
entries:
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2016/03/01/18:14:22
http://www.delorie.com
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #6 from winter-...@bfw-online.de ---
Judging from the correspondence regarding the fix for DJGPP [1] it seems that
DJGPP and SCO differ in their behaviour when it comes to relocating symbols in
absolute sections (== those with vma
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
winter-...@bfw-online.de changed:
What|Removed |Added
Summary|regression: missing |regression: erroneous
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #4 from winter-...@bfw-online.de ---
Reading further in the source code (and guessing a lot) maybe the we have a
section named A with VMA = 0 which means it requires no immediate relocation.
Later on when the linker adds new object
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #3 from winter-...@bfw-online.de ---
Created attachment 9034
--> https://sourceware.org/bugzilla/attachment.cgi?id=9034&action=edit
gdb session with ld
--
You are receiving this mail because:
You are on the CC list for
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #2 from winter-...@bfw-online.de ---
Hi Nick,
so it is quite hard to make up the scenario as one needs to design a COFF
structure just like the problematic one. Maybe debugging the linker can resolve
this more quickly.
While
https://sourceware.org/bugzilla/show_bug.cgi?id=19623
winter-...@bfw-online.de changed:
What|Removed |Added
Target||i586-pc-sco3.2v4.2
--
You
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: winter-...@bfw-online.de
Target Milestone: ---
Created attachment 8981
--> https://sourceware.org/bugzilla/attachment.cgi?id=8981&action=edit
Patch that
https://sourceware.org/bugzilla/show_bug.cgi?id=19030
--- Comment #5 from winter-...@bfw-online.de ---
> Yes, one dash or two makes a difference.
Using single-dash arguments can then be considered pretty dangerous in ld since
any small typo (or using a parameter that might only exist in s
https://sourceware.org/bugzilla/show_bug.cgi?id=19030
--- Comment #3 from winter-...@bfw-online.de ---
Even worse, the actual error is the missing dash in the beginning.
"--no-enum-size-warning" *is* a ld parameter but without the first dash it
behaves like "-n".
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=19030
--- Comment #2 from winter-...@bfw-online.de ---
Your analysis is correct, thank you.
While "-nostdlib" actually is a ld option (at least in my ld according to
--help and man page), I rechecked and noticed I passed another gcc para
droid/issues/detail?id=187
850
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: winter-...@bfw-online.de
Target Milestone: ---
Host
Assignee: unassigned at sourceware dot org
Reporter: winter-...@bfw-online.de
Target Milestone: ---
Created attachment 8642
--> https://sourceware.org/bugzilla/attachment.cgi?id=8642&action=edit
Git diff from Debian source repository to fix typo
https://sourceware.org/git/gitwe
16 matches
Mail list logo
