[Rprotobuf-yada] building on windows
eckuipers-web at yahoo.com
eckuipers-web at yahoo.com
Fri Feb 25 21:53:28 CET 2011
By doing "R CMD build --no-vignettes" and then "R CMD INSTALL" I still get the
same error, but it now happens on INSTALL (since build just makes a tarball and
does not try to load the package anymore). However now the package is installed
before the error is thrown and I can load the package.
The package works fine as far as I can see (my scripts that I was running under
linux all seem to work so far), however the package causes R to throw an error
upon exiting (which was exactly what happened with R CMD build and R CMD INSTALL
before).
So almost there... just have to figure out why R throws an error upon exit with
RProtoBuf loaded on windows. Do you have some exit hooks in the package perhaps?
Best, Koert
----- Original Message ----
> From: Dirk Eddelbuettel <edd at debian.org>
> To: eckuipers-web at yahoo.com
> Cc: Dirk Eddelbuettel <edd at debian.org>; rprotobuf-yada at r-forge.wu-wien.ac.at
> Sent: Thu, February 17, 2011 9:53:36 AM
> Subject: Re: [Rprotobuf-yada] building on windows
>
>
> Tough.
>
> On 17 February 2011 at 06:28, eckuipers-web at yahoo.com wrote:
> | Is SocketCopyingInputStream only used for the RPC (in which case its not
>vital)?
>
> | If i simply delete sisocks.h, SocketCopyingInputStream.cpp and
> | SocketCopyingInputStream.cpp then i get pretty far. it completes compilation
>and
>
> | tries to install, but then fails:
> |
> | g++ -shared -s -static-libgcc -o RProtoBuf.dll tmp.def
>ConnectionCopyingInputStr
> | eam.o ConnectionCopyingOutputStream.o ConnectionInputStream.o
>ConnectionOutputSt
> | ream.o DescriptorPoolLookup.o RSourceTree.o RWarningErrorCollector.o
>Rconnection
> | CopyingInputStream.o ZeroCopyInputStreamWrapper.o
>ZeroCopyOutputStreamWrapper.o
> | exceptions.o extractors.o lookup.o mutators.o rprotobuf.o streams.o
>wrapper_Arra
> | yInputStream.o wrapper_ArrayOutputStream.o wrapper_Descriptor.o
>wrapper_EnumDesc
> | riptor.o wrapper_EnumValueDescriptor.o wrapper_FieldDescriptor.o
>wrapper_FileDes
> | criptor.o wrapper_Message.o wrapper_MethodDescriptor.o
>wrapper_ServiceDescriptor
> | .o wrapper_ZeroCopyInputStream.o
>C:/Devel/R-2.12/library/Rcpp/lib/i386/libRcpp.a
> | -Lc:/Devel/mingw/msys/1.0/local/lib -lprotobuf -LC:/Devel/R-2.12/bin/i386
>-lR
> | Info: resolving google::protobuf::FieldDescriptor::kTypeToCppTypeMap by
>lin
> | king to __imp___ZN6google8protobuf15FieldDescriptor17kTypeToCppTypeMapE
>(auto-im
> |
>portc:/devel/rtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/l
> | d.exe: warning: auto-importing has been activated without
>--enable-auto-import s
> | pecified on the command line.
>
> Maybe that message is a clue?
>
> I would try to build a working standalone command-line program using the gcc
> / g++ version R uses here and the libraries you want to employ.
>
> One step at a time. The rest of the errors is to windows-y for me. Time for
>r-devel?
>
> | This should work unless it involves constant data structures referencing
>symbols
> | from auto-imported DLLs.)
>
> The MinGW sites may have help too.
>
> Dirk
>
> | installing to
>C:/DOCUME~1/kkuipers/LOCALS~1/Temp/Rtmp02U2BR/Rinst2ae067c3/RProto
> | Buf/libs/i386
> | ** R
> | ** demo
> | ** inst
> | ** preparing package for lazy loading
> | Loading required package: bitops
> | Warning: package 'Rcpp' was built under R version 2.12.1
> | ** help
> | *** installing help indices
> | ** building package indices ...
> | ** testing if installed package can be loaded
> |
> | * DONE (RProtoBuf)
> |
> | This application has requested the Runtime to terminate it in an unusual
>way.
> | Please contact the application's support team for more information.
> |
> | This application has requested the Runtime to terminate it in an unusual
>way.
> | Please contact the application's support team for more information.
> | -----------------------------------
> | ERROR: Installation failed
> | Removing installation dir
> |
> |
> |
> |
> | ----- Original Message ----
> | > From: Dirk Eddelbuettel <edd at debian.org>
> | > To: eckuipers-web at yahoo.com
> | > Cc: Dirk Eddelbuettel <edd at debian.org>;
>rprotobuf-yada at r-forge.wu-wien.ac.at
> | > Sent: Thu, February 17, 2011 8:53:08 AM
> | > Subject: Re: [Rprotobuf-yada] building on windows
> | >
> | >
> | > On 17 February 2011 at 05:39, eckuipers-web at yahoo.com wrote:
> | > |
> | > |
> | > | great i created a Makevars.win:
> | > |
> | > | ## This assume that we can call Rscript to ask Rcpp about its
locations
> | > | ## Use the R_HOME indirection to support installations of multiple R
> | version
> | > | RCPP_LDFLAGS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e
> | > | "Rcpp:::LdFlags()")
> | > |
> | > | ## The environment variables PROTOBUF_ROOT has to point to mingw
>directory
>
> | >with
> | >
> | > | subdirs include and lib containing protobuf headers and library
> | > | PKG_CXXFLAGS=-I$(PROTOBUF_ROOT)/include -I.
> | > | PKG_LIBS=$(RCPP_LDFLAGS) -L$(PROTOBUF_ROOT)/lib -lprotobuf
> | > |
> | > | now building moves along until i hit this error:
> | > |
> | > | g++ -I"C:/Devel/R-2.12/include"
>-I"C:/Devel/R-2.12/library/Rcpp/include"
>
> | >-Ic
> | > | :/Devel/mingw/msys/1.0/local/include -I. -O2 -Wall -c
> | >SocketCopyingInputStre
> | > | am.cpp -o SocketCopyingInputStream.o
> | > | In file included from SocketCopyingInputStream.cpp:1:0:
> | > | rprotobuf.h:28:0: warning: "O_BINARY" redefined
> | > |
> |
>>c:\devel\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/fcntl.h:67:0:
>
> | >no
> | > | te: this is the location of the previous definition
> | > | In file included from SocketCopyingInputStream.cpp:2:0:
> | > | SocketCopyingInputStream.h:5:24: fatal error: sys/socket.h: No such
>file or
>
> | >dire
> | > | ctory
> | > | compilation terminated.
> | > |
> | > |
> | > | So this has something to do with the infamous sockets on windows being
> | >different
> | >
> | > | i assume. SocketCopyingInputStream.h already indicates there might be
>an
>
> | >issue:
> | > | #include <sys/types.h>
> | > | #include <sys/socket.h>
> | > |
> | > | #include "sisocks.h"
> | > |
> | > | /* FIXME: this should be probably handled by sisocks
> | > | we need it for the TCP_NODELAY socket option */
> | > | #include <netinet/tcp.h>
> | >
> | > Yes, at this point you may be into porting territory. It might be a
good
> | > idea to look at Rserve by Simon Urbanek which includes a copy of
>sisocks.h
> | > too; and Simon is generally quite knowledgeable about these things.
> | >
> | > Can't be of much more help here, I am afraid.
> | >
> | > Dirk
> | >
> | > | ----- Original Message ----
> | > | > From: Dirk Eddelbuettel <edd at debian.org>
> | > | > To: eckuipers-web at yahoo.com
> | > | > Cc: Dirk Eddelbuettel <edd at debian.org>;
> | >rprotobuf-yada at r-forge.wu-wien.ac.at
> | > | > Sent: Wed, February 16, 2011 9:34:57 PM
> | > | > Subject: Re: [Rprotobuf-yada] building on windows
> | > | >
> | > | >
> | > | > On 16 February 2011 at 18:18, eckuipers-web at yahoo.com wrote:
> | > | > | Hey Dirk,
> | > | > | Building the google protobuf library under windows just works for
>me
>
> | >with
> | >
> | > | > | configure; make; make install. I was talking about RProtoBuf,
>which
>
> | >also
> | >
> | > | >seems
> | > | >
> | > | > | to have a configure script that i need to run.
> | > | >
> | > | > Oh, sorry, I misunderstood. You're ahead of the curve.
> | > | >
> | > | > Windows behaviour for CRAN package is standardized and document.
> | >Configure is
> | > | > never used. In most cases, locations are hardwired. Here is what
my
> | > | > RQuantLib package has in src/Makevars.win:
> | > | >
> | > | > ## This assume that we can call Rscript to ask Rcpp about its
> | >locations
> | > | > ## Use the R_HOME indirection to support installations of
>multiple R
>
> | > | >version
> | > | > RCPP_LDFLAGS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe"
>-e
>
> | > | >"Rcpp:::LdFlags()")
> | > | >
> | > | > ## The environment variable QUANTLIB_ROOT has to point to an
>existing
>
> | >build
> | >
> | > | >of QuantLib
> | > | > PKG_CXXFLAGS=-I$(QUANTLIB_ROOT) -I.
> | > | > PKG_LIBS=$(RCPP_LDFLAGS) -L$(QUANTLIB_ROOT)/lib
>-lQuantLib-mgw-0_9_9
> | > | >
> | > | > The first paragraph deals with Rcpp. LinkingTo: in Description gets
>the
> | > | > headers; the RCPP_LDFLAGS deals with the Rcpp library to link to.
>You
>
> | >could
> | > | > copy this as is.
> | > | >
> | > | > The second paragraph then sets the -I flag to find Quantlib header
>--
>
> | >adapt
> | > | > accordingly and for now don't bother with an env.var. It also sets
>the
> | > | > libraries, once for Rcpp from above and then for QuantLib.
> | > | >
> | > | > Enough of a pattern?
> | > | >
> | > | > Dirk
> | > | >
> | > | > | Best,
> | > | > | Koert
> | > | > |
> | > | > | ----- Original Message ----
> | > | > | > From: Dirk Eddelbuettel <edd at debian.org>
> | > | > | > To: eckuipers-web at yahoo.com
> | > | > | > Cc: rprotobuf-yada at r-forge.wu-wien.ac.at
> | > | > | > Sent: Wed, February 16, 2011 8:34:24 PM
> | > | > | > Subject: Re: [Rprotobuf-yada] building on windows
> | > | > | >
> | > | > | >
> | > | > | > On 16 February 2011 at 16:59, eckuipers-web at yahoo.com wrote:
> | > | > | > | Hey all,
> | > | > | > |
> | > | > | > | I again look again at building RProtoBuf on windows...
> | > | > | > | How do i start? The first thing is to do a ./configure i
>guess?
>
> | >Now i
> | >
> | > | >have
> | > | >
> | > | > | >my
> | > | > | >
> | > | > | > | regular mingw/msys environment in which i could try to do
>this.
>
> | >But R
> | >
> | > | >also
> | > | >
> | > | > |
> | > | > | > | comes with its own mingw compiler environment in Rtools. Does
>
> | >Rtools
> | >
> | > | >have a
> | > | >
> | > | > |
> | > | > | > | shell in which i could do the configure?
> | > | > | >
> | > | > | > When we mentioned this to Kenton, he looked surprised -- to
>him it
>
> | >just
> | > | > | > worked via 'configure; make; make install'. It was my
>understanding
>
> | >that
> | >
> | > | >he
> | > | > | > used just a regular MSys / MinGW environment for this.
> | > | > | >
> | > | > | > So if you have bit of patience to try this, I would suggest
>the
>
> | > | >following
> | > | > | > two-step:
> | > | > | >
> | > | > | > i) take the Protocol Buffers folks by their word and see if
>you
>
> | >can
> | >
> | > | >build
> | > | > | > a MinGW library and binary; this should work with a
>regular
>
> | >MSys
> | >
> | > | >but
> | > | > | > you may need to install a few tools; I recall it failed
>for me
>
> | >when
> | >
> | > | >it
> | > | > | > came to libtool so maybe I had a bad libtool version
> | > | > | >
> | > | > | > ii) with a library from i), we should be able to have R and
> | >RProtoBuf
> | >
> | > | >take
> | > | > | > advantage of it.
> | > | > | >
> | > | > | > Doing i) would be a really great help.
> | > | > | >
> | > | > | > We could even talk to Uwe to see if he'd want it for CRAN
>builds.
> | > | > | >
> | > | > | > Dirk
> | > | > | >
> | > | > | > --
> | > | > | > Dirk Eddelbuettel | edd at debian.org |
>http://dirk.eddelbuettel.com
> | > | > | >
> | > | >
> | > | > --
> | > | > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> | > | >
> | >
> | > --
> | > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> | >
>
> --
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>
More information about the Rprotobuf-yada
mailing list