[llvm-dev] RFC: A new llvm-dlltool driver and llvm-lib driver improvements

[Martell Malone via llvm-dev]

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>