Martell Malone via llvm-dev
2017-Mar-27 18:00 UTC
[llvm-dev] RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Just to follow up here I found some time to progress. Anyone who wants to follow along can see here. https://reviews.llvm.org/D29892 Kind Regards Martell On Tue, Feb 14, 2017 at 2:21 AM, Rui Ueyama <ruiu at google.com> wrote:> The code in LLD is somewhat tightly coupled with the rest of the linker. > Probably it is better to create a new library rather than trying to split > LLD into two. I believe this would result in a better API. Of course you > can reuse code, but what we need is a clean interface. > > The library shouldn't be complicated. In fact, it would export only one > function. > > std::vector<uint8_t> createImportLibrary(std::vector<ExportSymbol>) > > I.e. it takes a list of DLLExported symbols and returns a .lib file. > ExportSymbol type contains information about DLLExported symbols. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170327/bb04769d/attachment.html>
Martell Malone via llvm-dev
2017-May-11 10:00 UTC
[llvm-dev] RFC: A new llvm-dlltool driver and llvm-lib driver improvements
There are a few things running in parallel and thanks for taking the time to review and help me get this in tree. I wanted to follow up with a question on the linker side of things. Since rL289280 I can no longer link programs with the mingw-crt because of dup function errors of the main function. In mingw-w64-crt/crt/crtexe.c a main function is called from __tmainCRTStartup mingw-w64-crt/crt/crt0_c.c defines this main and calls WinMain in the case where main does not exist. What used to happen before was the crt0_c.c main would be ignored at link time because of priority on the users main function but now I just get a dup symbol error as there is no checking on priority anymore. On Mon, Mar 27, 2017 at 7:00 PM, Martell Malone <martellmalone at gmail.com> wrote:> Just to follow up here I found some time to progress. > Anyone who wants to follow along can see here. > https://reviews.llvm.org/D29892 > > Kind Regards > Martell > > On Tue, Feb 14, 2017 at 2:21 AM, Rui Ueyama <ruiu at google.com> wrote: > >> The code in LLD is somewhat tightly coupled with the rest of the linker. >> Probably it is better to create a new library rather than trying to split >> LLD into two. I believe this would result in a better API. Of course you >> can reuse code, but what we need is a clean interface. >> >> The library shouldn't be complicated. In fact, it would export only one >> function. >> >> std::vector<uint8_t> createImportLibrary(std::vector<ExportSymbol>) >> >> I.e. it takes a list of DLLExported symbols and returns a .lib file. >> ExportSymbol type contains information about DLLExported symbols. >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170511/a95afb0f/attachment.html>
Peter Collingbourne via llvm-dev
2017-May-11 17:41 UTC
[llvm-dev] RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Would it be possible to share a repro.tar file created with /linkrepro so that we can reproduce the problem? Peter On Thu, May 11, 2017 at 3:00 AM, Martell Malone <martellmalone at gmail.com> wrote:> There are a few things running in parallel and thanks for taking the time > to review and help me get this in tree. > I wanted to follow up with a question on the linker side of things. > > Since rL289280 I can no longer link programs with the mingw-crt because of > dup function errors of the main function. > > In mingw-w64-crt/crt/crtexe.c a main function is called > from __tmainCRTStartup > mingw-w64-crt/crt/crt0_c.c defines this main and calls WinMain in the case > where main does not exist. > What used to happen before was the crt0_c.c main would be ignored at link > time because of priority on the users main function but now I just get a > dup symbol error as there is no checking on priority anymore. > > > On Mon, Mar 27, 2017 at 7:00 PM, Martell Malone <martellmalone at gmail.com> > wrote: > >> Just to follow up here I found some time to progress. >> Anyone who wants to follow along can see here. >> https://reviews.llvm.org/D29892 >> >> Kind Regards >> Martell >> >> On Tue, Feb 14, 2017 at 2:21 AM, Rui Ueyama <ruiu at google.com> wrote: >> >>> The code in LLD is somewhat tightly coupled with the rest of the linker. >>> Probably it is better to create a new library rather than trying to split >>> LLD into two. I believe this would result in a better API. Of course you >>> can reuse code, but what we need is a clean interface. >>> >>> The library shouldn't be complicated. In fact, it would export only one >>> function. >>> >>> std::vector<uint8_t> createImportLibrary(std::vector<ExportSymbol>) >>> >>> I.e. it takes a list of DLLExported symbols and returns a .lib file. >>> ExportSymbol type contains information about DLLExported symbols. >>> >> >> >-- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170511/379ee814/attachment.html>
Apparently Analagous Threads
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements
- RFC: A new llvm-dlltool driver and llvm-lib driver improvements