Displaying 11 results from an estimated 11 matches for "createimportlibrari".
Did you mean:
createimportlibrary
2017 Oct 16
2
LLD COFF not closing mmaps to input files?
I've got a patched LLD 5.0.0 like this:
diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp
index 854c3e69..8bab1c11 100644
--- a/deps/lld/COFF/Driver.cpp
+++ b/deps/lld/COFF/Driver.cpp
@@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *>
ArgsArr) {
if (!Args.hasArgNoClaim(OPT_INPUT)) {
fixupExports();
createImportLibrary(/*AsLib=*/true);
-
2017 Aug 31
2
LLD: patch to fix libCOFF calling exit() on success in a library function
I believe that LLD is not supposed to call exit on success when you
call lld::coff::link.
>From downstream fork of LLD:
https://github.com/zig-lang/zig/commit/41da9fdb69065082f57c604b12eb02ca166cb18d
diff --git a/lld/COFF/Driver.cpp b/lld/COFF/Driver.cpp
index 854c3e69098..8b17f039870 100644
--- a/lld/COFF/Driver.cpp
+++ b/lld/COFF/Driver.cpp
@@ -1030,7 +1030,7 @@ void
2017 Oct 16
2
LLD COFF not closing mmaps to input files?
I think you want to call freeArena() before returning from lld::coff::link.
On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I believe this line is the culprit:
>
> COFF/Driver.cpp:102:
> make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); // take ownership
>
> Patch forthcoming.
>
>
> On Sun, Oct
2017 Aug 31
2
LLD: patch to fix libCOFF calling exit() on success in a library function
Correct, I am using libCOFF, libELF, and libMACHO all as a library. Ideally
all cases would return and report an error and clean up memory, etc,
instead of calling exit. However this is sufficient for my needs for now.
It is ok for LLD to crash if I supply an invalid command line argument, I
won't do that.
On Thu, Aug 31, 2017 at 5:47 PM, Rui Ueyama <ruiu at google.com> wrote:
>
2017 May 11
2
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
2017 May 21
2
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Hi Martell,
r289280 was not intended to be a significant functional change in the sense
that it would cause programs to fail to link, so this may be a bug I
introduced in r289280 (or one of the followup patches, which also changed
link order).
How is crt0_c.c being added to the link? If crt0_c.c is supplying a
definition of the main function I would expect it to be in an archive which
would
2017 Jun 15
2
Using LLD to create a .lib from a .def
On Wed, Jun 14, 2017 at 7:37 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Wed, Jun 14, 2017 at 4:24 PM, Andrew Kelley via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I'm copying some LLD code into my codebase like this:
>>
>> // workaround for LLD not exposing ability to convert .def to .lib
>>
>> #include <set>
>>
2017 Jun 16
2
Using LLD to create a .lib from a .def
I saw this change come in yesterday:
commit 572ad839e2f66eaa82ffc71b1061eb3d06a4d126
Author: Saleem Abdulrasool <compnerd at compnerd.org>
Date: Thu Jun 15 20:39:58 2017 +0000
COFF: add support for lib mode usage
When link is invoked with `/def:` and no input files, it behaves as if
`lib.exe` was invoked. Emulate this behaviour, generating the import
library from the
2017 Feb 14
3
RFC: A new llvm-dlltool driver and llvm-lib driver improvements
Well that means it would just be the only plan then.
I assume the first step would be to move the code from lld into this new
library and lld can use that? I can then re add the extra functionality for
weak externals?
We can then have lib and dlltool use this then.
On Tue 14 Feb 2017 at 01:58, Rui Ueyama <ruiu at google.com> wrote:
> On Mon, Feb 13, 2017 at 5:56 PM, Martell Malone
2017 Jun 14
2
Using LLD to create a .lib from a .def
I'm copying some LLD code into my codebase like this:
// workaround for LLD not exposing ability to convert .def to .lib
#include <set>
namespace lld {
namespace coff {
class SymbolBody;
class StringChunk;
struct Symbol;
struct Export {
StringRef Name; // N in /export:N or /export:E=N
StringRef ExtName; // E in /export:E=N
SymbolBody *Sym = nullptr;
uint16_t Ordinal
2005 Sep 21
2
cdecl and stdcall
Hi,
I'm trying to load a dynamic link library and it seems to work (is.loaded -> TRUE). When I run the function, which calls the .Fortran subroutine, R crashes!
I'v tried the same in S-Plus 2000 and it worked. Therefore I suppose that the dll has been compiled with the stdcall calling convention (and not cdecl). But the problem is that I don't have access to the source code,