Hi!
Thursday, 14 November, 2002 Nick Clifton [EMAIL PROTECTED] wrote:
NC Hi Charles, Hi Egor,
2002-07-01 Egor Duda [EMAIL PROTECTED]
* ldmain.c (main): Make runtime relocs disabled by default. Remove
assignment which has no effect.
* pe-dll.h (pe_create_import_fixup):
Congrats, Egor!
Nick Clifton wrote:
Approved and applied. [Sorry for the long delay].
Note: The cygwin targeted ports (eg i686-pc-cygwin) are currently
showing three unexpected failures in the GAS testsuite:
FAIL: i386 abs reloc
FAIL: i386 pcrel reloc
FAIL: i386 sub
Which their non-PE
This is an update of Egor Duda's original version. I have made no
substantive changes, except
1) remove the minimal portion which has already been accepted into
CVS as an interim measure (August 2002) while we were waiting for Egor's
copyright assignment for binutils to get in to FSF.
2)
What's the status of this change? I'd vote for including it in ld
iff it is only invoked when the option is specifically used. Then
we can add the appropriate changes to cygwin, make a new release, and
then make a binutils release as well.
cgf
On Thu, Jul 04, 2002 at 11:19:27AM +0400, egor
Hi!
Wednesday, 03 July, 2002 Charles Wilson [EMAIL PROTECTED] wrote:
CW The new version looks good to me; I built and ran your test without
CW problems. I do have a suggestion for later, when
CW --enable-runtime-pseudo-reloc is made the default: in pe-dll.c (around
CW line 2209) change
CW
On Tue, Jul 02, 2002 at 07:36:14PM +0400, egor duda wrote:
Ok, i've finalized patch and test. I suppose i have a copyright
assignment with FSF for this changes to get incorporated into official
sources. As far as i understand, i have to get an assignment form from
binutils maintainer, right?
Hi!
Tuesday, 02 July, 2002 Charles Wilson [EMAIL PROTECTED] wrote:
What i was talking about is 64-bit versions of windows where addresses
(and so base symbol values and addends are 64-bit). Or if we want to
add some other types of relocations. Adding type field will make it
possible to add
egor duda wrote
CW But why is this cygwin-specific? It seems that it's equally applicable
CW to mingw (e.g. native) DLLs, just as mingw's gcc can use the current
CW auto-import feature, even though MSVC can't understand or use it...
Well, of course it shouldn't be. I was thinking in
Hi!
Currently, --enable-auto-import feature of ld has a limitation of
not allowing importing dll data, which resides at some offset
from exported symbol. This limitation is derived from limitation of
native win32 loader which can't handle such imports.
There're ways to work around such
