Sure, it makes absolutely sense. Kai
2015-11-03 23:33 GMT+01:00 Martell Malone <[email protected]>: >> 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 <[email protected]> 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 <[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 > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
