similar to: Error 127 and dlltool

Hello: I'm trying to use Rcmd SHLIB to compile a single file, sann.c, to get sann.dll. I was able to get make libR.a to work, after going into MkRules and changing the line DLLTOOL=$(BINPREF)dlltool -k --as $(AS) to read DLLTOOL=C:/MINGW-1.1/bin/dlltool -k --as $(AS) But now I get: C:\rw1051\src\gnuwin32>Rcmd SHLIB sann.c make: make: Command not found make: *** [libR] Error 127

Ok, one last try. R1.2.0, WinNT 4.0: [R is installed in: R_HOME=D:\Programme\R\rw1020] Can anyone give a hint what the following error message (when running Rcmd INSTALL) means and what to do about it? cd D:\Programme\R\rw1020\src\library D:\Programme\R\rw1020\bin\rcmd install testfunctions make: Entering directory `/cygdrive/d/Programme/R/rw1020/src/gnuwin32' dlltool -k --as as --dllname

Hello, I am using cygwin (latest version) and I managed to generate a dll partly with rcmd shlib although there was a problem with both the resouce file (I had to remove "FILEOS VOS__WINDOWS32") and the command line for gcc (--shared is not supported for instance). So I would like to know which compiler/environment you advise to use for windows OS. Then I could load the library in R

Indeed, there is no file named "dlltool" anywhere around here! So, at last I am beginning to suspect that my collection of tools is incomplete. What I have got is "rw1020sp.zip" and "http://www.stats.ox.ac.uk/pub/bdr/RWin/tools.zip". These are properly istalled, I think. readme.packages says "If your package has no C nor Fortran nor C++ sources, see `Simple

It's doable to support dlltool-style import libraries by LLD. .idata sections in dlltool-style libraries are designed so that they will naturally construct the import descriptor table by just sorting them by section name. Supporting them is not hard. One thing we need to do is that currently we construct the import descriptor directly from short import libraries. We don't create

Hey guys, So I was able to modify dlltool to produce the exact same layout as lib.exe with the same section numbers etc. I've first managed to first create the correct section so that lld gives me link errors and then resolve those errors to create an exe. This is one thing that is still missing that sticks out like a sore thumb In the actual imports of the functions the objects are very

On Sat, Jul 25, 2015 at 5:24 PM, Martell Malone <martellmalone at gmail.com> wrote: > It's doable to support dlltool-style import libraries by LLD. .idata >> sections in dlltool-style libraries are designed so that they will >> naturally construct the import descriptor table by just sorting them by >> section name. Supporting them is not hard. > > > I

I forgot to attach the notes.txt with the objdump. On Thu, Jul 23, 2015 at 3:55 PM, Martell Malone <martellmalone at gmail.com> wrote: > Hi again rui, :) > > I've got all the patches into llvm and clang for supporting mingw-w64 via > compiler-rt and now we are able to build a full mingw-w64 toolchain without > gcc :) > With great help from yaron and rnk. > >

> > It's doable to support dlltool-style import libraries by LLD. .idata > sections in dlltool-style libraries are designed so that they will > naturally construct the import descriptor table by just sorting them by > section name. Supporting them is not hard. I don't really know my way around the code base of COFF well enough todo this myself. If you can point me in the

After some more digging and creating a few testcases in lld I have narrowed it down to The fact that dlltool generates Contents of section .idata$7: 0000 55534552 33322e64 6c6c0000 USER32.dll.. Where as lld expects Contents of section .idata$6: 0000 55534552 33322e64 6c6c0000 USER32.dll.. I recreated the hello64.test using dlltool for the lib and here is the asm dump of

Hey Rui, > I wonder how llvm-dlltool would fit in the entire picture of mingw > support. I don't think dlltool is the last missing piece. What do you need > to do other than that to fully support mingw using LLVM toolchain? Other then changing `lib/MC/WinCOFFStreamer.cpp` to not use -aligncomm within the EmitCommonSymbol function and a single patch for mingw-w64 itself to

Hi again rui, :) I've got all the patches into llvm and clang for supporting mingw-w64 via compiler-rt and now we are able to build a full mingw-w64 toolchain without gcc :) With great help from yaron and rnk. I've CC'd them as they might have interest in seeing this target through with me to the end :) So I have again turned my attention to LLD so that we can also remove ld as a

Hi Rui, Thanks for getting back to me on this Do you think that you can make dlltool to generate short import libraries? > If you can, it would be the easiest way to solve the issue. > On my current tests ld seems to not like libraries built with short import libraries so this would require an ABI break in binutils. dlltool has support for loads of legacy targets and changing this would

Hey llvm'ers, I have been working on a dlltool replacement for llvm. Here is my initial differential https://reviews.llvm.org/D29892 It is based on some functionality that already exists in lld. I added functionality to support, PE COFF Weak Externals and of course a front end to actually use it. I believe the work here can also be used for llvm-lib and lessen the load on lld. I would like

Ok, I think I may have a path or permissions problem (below). Anyone know which settings I should check? When I use "Rcmd SHLIB <filename>" I get: C:\Program Files\R\rw1081\bin>Rcmd SHLIB info.diffusion.c process_begin: CreateProcess((null), dlltool -k --as as --dllname R.dll --def R. exp --output-lib libR.a, ...) failed. make (e=2): The system cannot find the file

> > Also you need to make a change to LLD/COFF to accept GNU command > arguments, right? (Looks like you already have that patch locally.) Yes > My patch to hack lld into accepting some very basic gnu front end > arguments was enough to get all the above working which was enough to > develop further. On Mon, Feb 13, 2017 at 8:41 PM, Rui Ueyama <ruiu at google.com>

> > I wonder if it can be a wrapper for LLD/COFF. It can be an in-process > wrapper, meaning that you could add a main function for mingw which > translates all arguments into the MSVC style and then invoke the COFF > linker's main function. That should work, if I am understanding this correctly I can create an argument parser (probably partially based on the ELF one) then I

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

> > No, I meant an even thinner wrapper which textually translates arguments. > For example, the wrapper would translates "/out:foo.exe foo.obj" to "-o > foo.exe foo.obj" and then call lld::COFFF:link(). It doesn't do anything > with Config object nor LinkerDriver::run and have absolutely zero knowledge > on the internals of LLD. Ohh okay I misunderstood.

Hi Martell, Sorry for the belated response. I missed this email. I took a quick look at the library file you have attached and noticed that the file consists of regular object files. LLD expects that all dllimported symbols are described using "short import library" (PE/COFF spec 7). Because I didn't test LLD with dlltool-style archive files, it's no surprise that it didn't