similar to: R and gcc, yet again

Hello: Many thanks to Professor Ripley for responding to my earlier post, included below, about trying to use mingw32 gcc.I did put back the original Rinternals.h. I am still crashing R every time I try to use C code. Here is what I did, basd on readme.packages: 1.) Ensured that C:\Rtools was first in my path, and obtained a new tools.zip from BDR's R tools site. 2.) Ensured that I

Hello: I am looking at "Writing R Extensions", subsection 3.6.4, using R 1.1.0, under NT4.0, with VC++ 6.0. Under these conditions I can use the first method given for coding the out() function, but not the second, which uses getAttrib() and setAttrib(). I hope that someone will tell me how this second method can also be made to work. Details follow, for anyone kind enough to help.

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -------------- next part --------------

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but

On 01/23/17 01:01 AM, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> >GCC supports __declspec(dllexport) though it still needs a def file, >> >with no exports. Libtool doesn't currently and as flac uses libtool... > So you're happy with this patch? > > http://lists.xiph.org/pipermail/flac-dev/2017-January/006170.html > No. Lots of errors such

Full_Name: Byron Ellis Version: 1.2.2 OS: all Submission from: (NULL) (140.247.105.95) R_ext/Arith.h #ifdef MAIN #define extern #endif #ifdef __cplusplus extern "C" { #endif these two should be reversed. Its never a problem because builds aren't done against C++ compilers, but its still an error (just a low priority one). also, you could change that to #ifdef __cplusplus extern

After a long processing, I was able to create a version of a small C# class that was able to emulate the rproxy by P/Invoke. This is mostly to find a workaround a performance problem of the StatConnector. It's almost work but ... I have strange memory exception when I call the print function. The variable seems to not survive from one call to the other. As there is no debug symbol for

Óscar Fuentes <ofv at wanadoo.es> writes: > Michael Spencer <bigcheesegs at gmail.com> writes: > > The problem is that MSVC++ requires sprinkling > > __declspec(dllexport/dllimport) all over the code, and we really don't > > want to deal with maintaining that, as most developers have little to > > no experience with Windows DLLs. > > BTW, you

Hi Nico, Thank you for your feedback. I'll try to answer your questions below. > What problems do you expect with another approach? I have a local > prototype that removes dllimport/export as linkage and uses function > attributes and an extension to globals. I decorate dllexported functions with > the Used attribute and it seems to work fine. This allows such functions to >

On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com> wrote: > Hi, > > From what I have seen on this mailing list and elsewhere, it would seem that > it isn’t possible to build LLVM as a shared library using Visual C++. Still, > I would imagine that quite a few people are or would be interested in it, > so… is there any plan to support this any time soon? This,

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C39C9F.B5DABBD0 Content-Type: text/plain; charset="iso-8859-1" # Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing

It was recently brought to my attention by "Ram'on Garc'ia Fern'andez <ramon@jl1.quim.ucm.es>" that there is yet an even simpler solution to the issue of cross-DLL access of variables in the data segment. Although a variable may be exported either from the module definition file, or explicitly via _cdeclspec(dllexport) -- unlike procedures (functions), it is mandatory

Óscar Fuentes <ofv at wanadoo.es> wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > nobled <nobled at dreamwidth.org> writes: > >> The LLVM 2.7 release notes say you can use ./configure --enable-shared >> to build LLVM as a shared library (libLLVM2.7.so), and the LLVM tools

I am trying to build Clang/LLVM with -DLLVM_BUILD_LLVM_DYLIB=ON and -DLLVM_LINK_LLVM_DYLIB=ON to reduce the size of toolchain. I am getting LINK error 1181 about `lib\LLVM.lib` not found. After investigating, `lib\LLVM.lib` is supposed to be produced along with `bin\LLVM.dll`. `bin\LLVM.dll` is indeed produced, but it does not contain any exported symbols (10KB only) because LLVM does not use

On Fri, Mar 23, 2012 at 9:45 PM, JonY <jon_y at users.sourceforge.net> wrote: > On 3/23/2012 13:59, Glenn McCord wrote: >> Hi. I'm trying to get a project linking to libFLAC_static.lib but I >> get linker errors such as the following. >> >> The __imp__ prefix seems to imply that some kind of .dll usage is >> happening, which it shouldn't. >>

Ok, I have just found the cause of the error messages I am getting, and it now makes sense to me why the 'normal' build works fine on Windows, Linux and OS X, and why my personal build works on Linux and OS X, but not on Windows. However, I still don't understand why I am getting the error messages I am getting. Anyway, it has to do with wanting to export some classes and function,

On 12/2/2011 9:09 AM, Alan Garny wrote: > > However, there is one new (minor) issue which is that when building my > application I get a warning from the linker about auto-importing > having been activated without --enable-auto-import being specified on > the command line. Indeed, for some reason, the vtable for > llvm::CallInst has to be resolved...?! This is clearly not

nobled <nobled at dreamwidth.org> writes: >>> The LLVM 2.7 release notes say you can use ./configure --enable-shared >>> to build LLVM as a shared library (libLLVM2.7.so), and the LLVM tools >>> will link against that instead of including the static libraries, so I >>> was wondering: >>> >>> Is there a way to configure LLVM the same way