[Rprotobuf-yada] building on windows
eckuipers-web at yahoo.com
eckuipers-web at yahoo.com
Thu Feb 17 15:28:16 CET 2011
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.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.)
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
>
More information about the Rprotobuf-yada
mailing list