similar to: WATCOM compiled libraries

The attached set of patches adds support for OS/2 using Watcom compiler (tested with Open Watcom 1.9). My only interest was building a working dll (the last patch in the set adds a makefile for it), therefore I did not touch other places: If there is interest, I can do so. Regards. -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name:

A colleague is using Watcom F77 version 11 in Windows NT, and wants to create DLLs callable from R. (He was previously able to do external calls from S-PLUS). Does anyone know what magic is necessary so that it uses the right calling convention? In a debugger, it appears it's using a register-based calling convention, no matter what we ask for, but we're probably asking in the wrong

Hello. I am trying to use a FORTRAN subroutine from within R (Windows version). This fortran subroutine is compiled using the Open Watcom Fortran compiler and the compiled object file is called ritscale.obj. Following the explanation on pages 193-194 of "The New S language" I use the dyn.load command: > dyn.load("f:/maxent/ritscale.obj") Error in dyn.load(x,

On 1/22/17, Dave Yeo <dave.r.yeo at gmail.com> wrote: > On 01/22/17 09:57 AM, Ozkan Sezer wrote: >> On 1/22/17, Dave Yeo <dave.r.yeo at gmail.com> wrote: >>> On 01/22/17 05:35 AM, Ozkan Sezer wrote: >>>> The attached set of patches adds support for OS/2 using Watcom compiler >>>> (tested with Open Watcom 1.9). My only interest was building a

On 01/22/17 05:35 AM, Ozkan Sezer wrote: > The attached set of patches adds support for OS/2 using Watcom compiler > (tested with Open Watcom 1.9). My only interest was building a working > dll (the last patch in the set adds a makefile for it), therefore I did > not touch other places: If there is interest, I can do so. Most of the patches can have s/__EMX__/__OS2__/ excepting the

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

Dear Moderator, I downloaded Vorbis 1.2.0 code from your website and I tried to build a project in Visual studio 2008, as the earlier version was created in VC 6 version it has been modified here. In the solution I have 6 projects vorbis_dynamic, vorbis_static, vorbisenc_dynamic, vorbisenc_static, vorbisfile_dynamic, vorbisfile_static. When I tried to built the project, it shows error that it

This adds checks for Watcom C DOS cross-compiler in a manner analogous to mingw compiler for Windows. The compiler is not commonly present in Linux distributions due to a non-free license. Signed-off-by: Lubomir Rintel <lkundrak at v3.sk> --- dosutil/Makefile | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/dosutil/Makefile b/dosutil/Makefile index 9dc88d1..69fc58a 100644 ---

On Tue, Jun 30, 2015 at 12:30:35PM -0700, Eric Lindblad wrote: > I don't know if it would be of any use - and I know that > the configure script searches for gawk, sed and grep - > but Watcom has free 32 and 64 bit compilers, and > the msvc files for Xapian no longer appear to be > maintained, so perhaps Xapian build files written for > [Open] Watcom could be made, as such

I have a query after finding an error running Rtools on a Windows machine. I am trying to build an update to the R fda library using Rtools27 under Windows XP Pro. This is the current fda library on RForge: http://r-forge.r-project.org/projects/fda Following R CMD build, R CMD check produces the following error in 00Install.out: installing R.css in F:/work/RForge/fda.Rcheck make: ***

Has anyone ever successfully used Fortran character strings with R? ?Foreign says R C Fortran integer int * integer .... character char ** [compiler dependent] Character strings are passed as C arrays of character strings to Fortran: the first string may be usable if its length is passed

On Thu, 14 Dec 2000 10:06:39 +1100, Michael Smith wrote: >>I've done a port for OS/2 using Watcom C++, including a simple command line >>player based on vorbisfile_example.c, which can be downloaded from >>http://silk.apana.org.au/utils.html >>It'd be nice if my changes could be commited to CVS, should I just post >>patches here? > >Yes, unless

Since lot of people want this thing, I will try to take a stab at it. For now, I will hard code the menu in the code, and then somebody else can remove that restriction. May be we can add some kind of keyword to the config file which syslinux ignores and the comboot menu does something with it. I have one question about comboot: If I write a DOS program using C (compiled using watcom -3 -mt -osx

Hello! Is it possible to make the sources a bit more portable? I'm on QNX4 with Watcom C v10.6B which has no support for int64. I'd like to be able to compile as many modules as do not depend on int64. (Currently I do not need SFTP that bad, the SSH is enough for me) -- Best regards, Anthony mailto:rz1a at mail.ru

Hello again R People: I'm still stuck on my packages and FORTRAN problem. I made a directory called erin, (in the library tree) I created a sub-directory called R, in which I put my R source code. I created a sub-directory called libs, in which I put my FORTRAN program, (compiled and made into a DLL). Here is my output > library(erin) Warning there is no R source code in erin I also

Ozkan Sezer wrote: > Anyways, with the changed exports.h patch, every need should > be met now.. Sorry, which patch is that? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

I have made available the work of the last weekend that I mentioned in my previous messages on ftp://sirio.stat.unipd.it/pub/R. Many thanks to Peter D. and Ross I. for their suggestions. If you think that the work is of some interest, I can upload it to CRAN. guido m. This is the README enclosed in the distribution. -------------------------------------------------------------------------

On Jul 30, 2013, at 12:41 PM, Stephen Lin wrote: >> Right. What's the point of all the effort devoted to MSVC++ ABI >> compatibility when Clang doesn't need it for being a top-notch C++ >> compiler on Windows? > > I brought up a similar point a little bit earlier, too.... > > It seems like the only necessary condition for being a first-class >

On 01/22/17 02:00 PM, Ozkan Sezer wrote: > Question: Does emx support __declspec(dllexport) so I can adjust > these changes? Because the emx build of the dll seems to have > exported_everything_ :( GCC supports __declspec(dllexport) though it still needs a def file, with no exports. Libtool doesn't currently and as flac uses libtool... Dave

for a while after 1.0, in CVS, there was code to check for OS support for SSE instructions. since that required a fork() inside the library I have decided to remove it. so now to get SSE support you have to configure with --sse-os. if I think of a clean way to implement this I'll put it back in. also, there's been some suspicion that the 3dnow! stuff is causing crashes, so I disabled