bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll


From: tkacvins at gmail dot com
Subject: [Bug binutils/30448] ld fails to make a valid DLL when used with gnatdll
Date: Tue, 16 May 2023 18:13:42 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=30448

--- Comment #12 from Tom Kacvinsky <tkacvins at gmail dot com> ---
(In reply to Eric Botcazou from comment #11)
> > The problem is an access violation at startup, deep in the guts of the DLL
> > loader.  Doing a debug session with Visual Studio and looking at registers
> > and memory locations, it was determined that loading the DLL in question is
> > where things went south.
> 
> For a DLL generated by GNAT?  Which version of GNAT is that?

GNAT that comes from GCC 12.1.0.  I am using MSYS2 + MinGw-w64 for my base
setup, then compile a custom GCC 12.1.0 with mingw-w64-crt v10.0.0 and binutils
2.38.  This includes MinGW-w64's support for the UCRT, as we need that for the
version of Visual Studio we also use to build out product.

> 
> > And, for what it's worth, perhaps --disable-reloc-section is not a good name
> > for an option - the DLL I produced with that option does have a .reloc
> > section.  So what exactly does --disable-reloc-section mean if specifying
> > that option still results in a DLL with a .reloc section?
> 
> So it generates a different .reloc section?

Yes, binutils 2.35 generates a different .reloc section than binutils 2.36
(with default options) unless one uses binutils 2.36 with
--disable-reloc-section.

I shall gather what files I can attach that don't contains the proprietary
binary code, just the relocation information.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]