Request: make coff2omf free
Frits van Bommel
fvbommel at REMwOVExCAPSs.nl
Sun Feb 25 10:27:00 PST 2007
John Reimer wrote:
> On Sun, 25 Feb 2007 10:48:36 +0100, Frits van Bommel wrote:
>
>> John Reimer wrote:
>>> On Sat, 24 Feb 2007 22:33:11 -0800, Walter Bright wrote:
>>>
>>>> Why does Mingw do coff on Win32, while the gcc tools everywhere else do
>>>> elf? This makes no sense to me.
>>>
>>> It seems that elf is an object /and/ executable format, so it requires
>>> support from the OS somehow.
>> Only if you use the executable format. I don't see any reason it
>> couldn't be used as an object format (unless PE executables need
>> information ELF has no way to represent).
>
> Okay, thanks. That clarifies things a little. So elf must have two
> formats in one,
Actually, there are _three_ types.
There are relocatable files (typically named *.o) that can be linked
together to create the other formats.
Then there are executable files that are "suitable for execution", i.e.
programs. Typically named without file extension.
And lastly, there are shared object files, that can be either further
linked with other shared object files and relocatable files, or
dynamically loaded at runtime.
These are typically used for dynamic libraries (the second use
mentioned), like DLLs are on Windows. They're typically named *.so or
*.so.*, with the last asterisk containing a version number (e.g.
libc.so.6 or libreadline.so.5.1).
> and the object elf format is not dependentant on the elf
> executable format?
The formats are very similar, and described in the same standard, but
AFAIK they don't actually depend on each other.
The header contains a field that defines which type it is (there are
also defined values for 'core' files (produced on crash) and
processor-specific formats, but their contents aren't specified.
Some of the differences between the formats that _are_ defined are
slight differences in the meanings of some fields (e.g. absolute vs.
relative addresses) and the fact that some entities are optional for
some formats. For example, relocatable files don't need to have a
program header.
> So really it comes down to whether the elf object
> format can embed in a PE?
Yes, pretty much.
> Further, for elf shared libraries, I assume
> having an appropriate dynamic linker is still important.
Maybe DDL can help here. Or a bit of other (standard?) library support.
> Strangely finding information like this online is extremely difficult.
About ELF or about linking it to PE?
There's plenty of information about ELF available. Just google for
"executable linkable format" instead of "ELF", since Google isn't
case-sensitive ;)
There might be no info about linking ELF to PE, but that could just be
because nobody has been crazy enough to try it yet :P.
> All I know is that there was a project (several years ago ~1999)
> that provided a elf-linker/loader for NT which now has fallen into
> non-existance: it was called cross-elf.
I never heard of that project, but if it was around 1999 that doesn't
surprise me.
>>> Whereas coff is merely an object format and PE appears to be windows
>>> executable format.
>>>
>>> That may be the reason that mingw went coff instead, even it it isn't
>>> compatible with MS coff objects.
>> IIRC mingw is compatible with *some* MS .lib files. It may be just
>> import libraries, and/or just C libraries.
>> I remember there being *-msvc and *-mingw .libs for one library (I think
>> it was Allegro or SDL or some such) where the difference was _what they
>> were compiled with_, not _what they could be used with_. In fact, IIRC
>> it was recommended to use the *-msvc libs even for mingw...
>
> Yes, this might be possible, but I'm not sure how it works, since I read
> online somewhere that mingw uses a different naming convention for its
> coff as well as other small changes (dss). Maybe the mingw linker (ld)
> understands more than its own coff variation, however. That
> makes mingw look even better in my eyes. I know mingw ld.exe supports a
> whole bunch of other linker formats including elf -- huge bonus. The only
> one it doesn't support is OMF! :)
Are you sure mingw ld supports ELF?
I'm pretty sure I've gotten "PE operation on non-PE file" or some such
error multiple times when I accidentally used mingw ld to link ELF
objects. (I was cross-compiling)
If it _can_ already support ELF objects to PE executable, that's news to
me. But I haven't tried it lately, so it may just have been fixed.
More information about the Digitalmars-d
mailing list