Hello Martell,

Great work. Please go ahead and merge new tool to master.
I agree to Adrien's comment that this tool should be also buildable by
different hosts. So we shouldn't bind its build on Windows-targets
only.

Thanks,
Kai

2015-11-03 22:33 GMT+01:00 Adrien Nader <[email protected]>:
> Hi,
>
> On Thu, Oct 29, 2015, Martell Malone wrote:
>> Hi,
>>
>> Kai and I discussed this previously but I would like to present to everyone
>> a tool to generate import libs based on layout and code structure of gendef.
>>
>> I would like propose
>> https://github.com/martell/genlib
>> to be merged as part of the mingw-w64 project.
>>
>> There are a couple of advantages over using this to dlltool.
>>
>> 1. This tool supports the following targets armv7 aarch64 i686 and x86_64.
>>     where as dlltool currently supports just i686 and x86_64
>>     (and a really old arm target thats not NT)
>>
>> 2. The target is specified at runtime so one build will do for all targets.
>>     (this will be especially useful for cross compiling)
>>
>> 3. This tool unlike dlltool complies to the PE/COFF spec 7.
>>     Import Library Format. so that we can interop with other linkers
>> besides ld.
>>
>> The 2 most common use cases would be
>>
>> 1. Using llvm's linker lld which is now feature complete for COFF on arm
>> x86 and x64.
>> 2. Generate an import lib for msvc to use which dlltool could not do.
>
> These are really great news, thanks for the work! :)
>
>> I would like to propose we initially have a flag to enable using this when
>> building the crt. Some of the autotools experts here may know some more on
>> that. This is because currently ld does not support PE/COFF spec 7 and does
>> not understand the resulting library.
>
> I believe it is best outside of the CRT's build process actually.
>
> If you require it as part of the CRT's build, you'll have to build it
> first which will be an issue for native builds. Sure you could build the
> CRT without and then rebuild it with it but it's not very friendly to
> make the compiler bootstrap chain longer (there's already GCC [possibly
> twice], binutils, the CRT [possibly the headers separately],
> winpthreads, and soon genlib once).
>
> I believe it is better to keep its build separate but be able to do
> something similar to:
>   ./configure --with-mingw-w64-sources=.....
> And it would build itself as it currently does and would then build the
> .lib files too.
>
> --
> Adrien Nader
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to