similar to: R solaris 64 (etc) build errors

We have a solaris/sparc machine that has been running an old version of R-devel: Version 2.2.0 Under development (unstable) (2005-06-04 r34577) which was built as m64 from sources. Attempting to upgrade to 2.4.0 the configure step goes ok, but I'm getting early on from make: > gcc -m64 -L/opt/sfw/lib/sparcv9 -L/usr/lib/sparcv9 > -L/usr/openwin/lib/sparcv9 -L/usr/local/lib -o

On Mon, 7 Nov 2005, Bill Wendling wrote: > What's the config.log from this run? its attached. -Tanya > > -bw > > On 11/3/05, Tanya Lattner <tonic at nondot.org> wrote: >> >> Following the instructions here: >> http://llvm.cs.uiuc.edu/docs/TestingGuide.html#run >> >> I get an error running configure in the llvm-test directory. >>

Hello I'm having trouble building R under Unix. I've searched for information about it on google or the R database but I didn't find any answer on my problem. I would be thankful if somebody could help me working that out. The version of R I'm trying to build is R-2.4.0 and the architecture of solaris is sparc. Here's what I type. PATH=/opt/sfw/bin:$PATH export

Full_Name: Ricardo Aponte Version: R 2.4.0 OS: Solaris 10 Submission from: (NULL) (200.71.37.195) Hello I'm having trouble building R under Unix. I've searched for information about it on google or the R database but I didn't find any answer on my problem. I would be thankful if somebody could help me working that out. ./configure R is now configured for

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

Dear R-HELP, We are compiling R-2.12.1 for 64 bits onto a Sun Sparc machine below: SunOS 5.10 Generic_142900-13 sun4u sparc SUNW,Netra-T12 The source was compiled successfully with "gcc version 3.4.6" by using the default configuration and has produced R-2.12.1 in 32 bits. Compiling R-2.12.1 for the 64 bits by configuring the config.site file as follow: CC="gcc -m64"

Hi, I've been having similar experiences and haven't been able to substantially improve the efficiency using the guidance in the I/O Manual. Could anyone advise on how to improve the following scan()? It is not based on my real file, please assume that I do need to read in characters, and can't do any pre-processing of the file, etc. ## Create Sample File

Hi, I attempted to build v3.3 using Sun Studio 12, but it failed right out of the gate. It looks like it can't find the standard libraries, but according to the make output, it's looking in the right places. Would someone please clue me in as to what I'm missing? Thanks. -John Using FLAGS = -I/opt/heimdal/include -I/usr/sfw/include/openssl -g -xs -xtarget=ultraT1

I found 179 more *.{c,cpp,h} files with tabs. Unfortunately, the tabs stops used vary so blindly expanding them messes up alignment in many cases :( Index: examples/BFtoLLVM/BFtoLLVM.cpp Index: include/llvm/AbstractTypeUser.h Index: include/llvm/GlobalVariable.h Index: include/llvm/InstrTypes.h Index: include/llvm/IntrinsicInst.h Index: include/llvm/ADT/PostOrderIterator.h Index:

Overall the build process for dovecot is very clean. I did however run into a significant problem when it came to locating the mysql libraries, especially when building a 64 bit executable but similar problems occured building a 32 bit executable. I am describing the 64 bit build issues below since that is the worst case scenario. Fixing the 64 bit build will automatically fix the 32 bit

I recently patched my Solaris server and suddenly my Samba service is not working correctly. When Anyone accesses a samba share the samba daemon panics and shuts down. Solaris than restarts the system, unless there are multiple panics simultaneously than the service is placed in maintenance mode. The SAMBA server is a stand alone supporting a dozen end users for a large file store behind the

I recently patched my Solaris server and suddenly my Samba service is not working correctly. When Anyone accesses a samba share the samba daemon panics and shuts down. Solaris than restarts the system, unless there are multiple panics simultaneously than the service is placed in maintenance mode. The SAMBA server is a stand alone supporting a dozen end users for a large file store behind the

Hi, I am trying to compile R-2.2.1 on Solaris 2.9 with a 64-bit build. Following the instructions in "R Installation and Adminstration", I changed the following settings in "config.site": CC="gcc -m64" F77="g77 -64" CXX="g++ -m64" LDFLAGS="-L/usr/local/lib/sparcv9 -L/usr/local/lib" But I got the following error messages:

Hello all listies. I've got samba4.0.6 running on FreeBSD 9.1. Joined W2K12 domain as member server. running getent group I noticed it takes a long time to resolve groups. The result is correct, but it is inordinately long. With 3.6.13 on FreeBSD 9.1 the return is nearly instantaneous. smb4.conf looks like this. [global] workgroup = TMS3 security = ADS realm = TMS3.COM encrypt

Hi, been trying to build R-1.5.1 for som eof our users here. No probs with gcc-3.2 32-bit installtion, but thought we'd try it with the 64-bit just for the crack. Configuring thus CC=gcc3 CFLAGS="-m64" CXX=g++3 CXXFLAGS="-m64" F77=g773 FFLAGS="-m64" LDFLAGS="-m64 -L/usr/local/packages/gcc-3.2/lib/sparcv9" ./configure

On 03/02/2010, at 10:16 PM, Anton Korobeynikov wrote: > Hello, Nathan > >> I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit

Hi, I am compiling R2.8.1 on a Sun M4000 machine with Solaris 10. I am using Sun Studio 12. I get the following error: cc -xtarget=native64 -G -L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9 -o grDevices.so chull.o devNull.o devPicTeX.o devPS.o devQuartz.o init.o mkdir ../../../../library/grDevices/libs Warning in solve.default(rgb) : unable to load shared library

We currently have a samba install on Solaris 8 providing a front-end to a Rational ClearCase system. Because of some recent changes, we are having Kerberose issues in validating files (too many open files). After some research, I found that the best way to resolve these is to re-compile samba as a 64bit application to increase the open file restrictions on a Solaris 32 bit app. The problem I am

Hi list, I tried to install MCMCpack to R-2.12.0, got the following error, CC -m64 -library=stlport4 -I/apps/sparcv9/R-2.12.0/lib/R/include -DSCYTHE_COMPILE_DIRECT -DSCYTHE_DEBUG=0 -DHAVE_TRUNC -DHAVE_IEEEFP_H -I/opt/csw/include -KPIC -g -c MCMCSVDreg.cc -o MCMCSVDreg.o "error.h", line 598: Error: The function "abort" must have a prototype.