Re: problem with nlmconv

[Ian Lance Taylor <ian at zembu dot com>]

Günter Knauf <eflash@gmx.net> writes:

> here are my problems:

Note that nlmconv hasn't been supported for years.  In fact, it's not
clear that it was ever supported--I wrote it in the first place, but I
was never interested in using it, the contract for which I wrote it
was cancelled, and I'm not sure anybody has ever seriously used it for
anything.  Looking at the ChangeLog, there have been on substantial
changes to nlmconv since 1994.  You're pretty much on your one with
this.

> I'm trying to compile a NLM with Mingw32 (netware loadable module), but have some problems: nlmconv from binutils only recognizes ELF objects. With the latest binutils (which are compiled to support ELF) I'm now able to convert from the PE to the ELF format with objcopy, but then I had problems because the symbols have a leading underscore. So I used:
> objcopy -O elf32-i386 --remove-leading-char $(TARGET).o
> and this seems to work, but still one symbol (__main) isnt found...

The symbol __main is normally found in libgcc.a.  It arranges to run
global constructors.  You can probably supply your own version which
does nothing.

> The other way could be to compile nlmconv so that it recognizes PE format if this is possible (I assume yes), but I'm not familiar with building cross compilers; and the version I have was compiled by a Mingw32 developer who did it for me...

In principle nlmconv should work if you give it a PE format input
file.  There is no need to buld a cross compiler.  Just build using
--enable-targets=i386-pe.  You will probably have to fix
i386_mangle_relocs in nlmconv.c, since it will probably manage to do
the wrong thing.

If all this doesn't make any sense to you, I would have to recommend
that you hire a consultant.  This is all black magic which nobody
uses, and you are on your own.

Ian