> > 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.
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. Just to clear things up here. I intend to include the source into the mingw-w64-tools folder so building for any host should not be a problem. As for the option I just would like a configure option in the crt to force using it instead of dlltool. ./configure --use-genlib It should not affect the current building in anyway and can be enabled by choice. Does my explanation this make sense? On Tue, Nov 3, 2015 at 11:04 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 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 <adr...@notk.org>: > > 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 > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > ------------------------------------------------------------------------------ > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
