Segin wrote:
Alexandre Julliard wrote:
Troy Rollo <[EMAIL PROTECTED]> writes:
1. Modify the executable after the link phase;
2. Put what we can into SizeOfImage (which could only be one part of the
calculation - presumably "_end") and adjust at load time; or
3. Don't rely on the assembler
Alexandre Julliard wrote:
Troy Rollo <[EMAIL PROTECTED]> writes:
1. Modify the executable after the link phase;
2. Put what we can into SizeOfImage (which could only be one part of the
calculation - presumably "_end") and adjust at load time; or
3. Don't rely on the assembler to
Troy Rollo <[EMAIL PROTECTED]> writes:
> 1. Modify the executable after the link phase;
> 2. Put what we can into SizeOfImage (which could only be one part of the
> calculation - presumably "_end") and adjust at load time; or
> 3. Don't rely on the assembler to put anything meaningful in there an
On Wed, 28 Dec 2005 20:38, Alexandre Julliard wrote:
> It's relative to the start of the NT header, and it gets relocated at
> load time when we map the NT header to its proper place, at the start
> of the .text section.
OK. We still have the problem that on a SPARC there is no way at the time of
Troy Rollo <[EMAIL PROTECTED]> writes:
> On the other hand it seems this field ends up with the wrong value under x86
> anyway, since the calculation is "_end - .L__wine_spec_rva_base".
> ".L__wine_spec_rva_base" is in ".data", which in kernel32.dll.so on my system
> is section 21 at 0xb6940 -
On Fri, 23 Dec 2005 19:18, Alexandre Julliard wrote:
> Troy Rollo <[EMAIL PROTECTED]> writes:
> > This will work if (and only if) the value of SizeOfImage is unimportant
> > for Winelib executables. Of course in that case there is probably some
> > merit in setting it to zero anyway since at least
Troy Rollo <[EMAIL PROTECTED]> writes:
> This will work if (and only if) the value of SizeOfImage is unimportant for
> Winelib executables. Of course in that case there is probably some merit in
> setting it to zero anyway since at least that would make it obvious that it
> has no meaningful va
On Thu, 22 Dec 2005 19:52, Alexandre Julliard wrote:
> You can probably fix it by defining an _end symbol, like we do for
> MacOS. You certainly don't want to try modifying the binary after it
> has been built.
This will work if (and only if) the value of SizeOfImage is unimportant for
Winelib e
Troy Rollo wrote:
winegcc from the current WineHQ produces assembly output for SPARC systems
that cannot be processed by the assembler.
I've attached the patches we're using for winebuild on SPARC. This
fixes both of the problems you're encountering. I'm not sure if the fix
is the right o
Troy Rollo <[EMAIL PROTECTED]> writes:
> 2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data
> section}"
>
> This problem is more sinister. It arises from the same limitation as the
> first
> problem, but is not susceptible to being worked around. The offending code is
>
winegcc from the current WineHQ produces assembly output for SPARC systems
that cannot be processed by the assembler.
1. "operation combines symbols in different segments" error.
This problem arises because the imports code attempts to generate a relocation
involving symbols in different segmen
11 matches
Mail list logo
