similar to: problem building R 2.9.1 from source on RHEL 4 (x86_64)

I am having trouble using Jim Lindsey's libraries because of unresolved symbols. I am currently using R 0.65.0, but had this problem in earlier releases as well. I have a RedHat 6.0 Linux on i386 and use egcs (upgraded to that distributed with rawhide, after first failures with the libraries): egcs-g77-1.1.2-19 egcs-1.1.2-19 Installation of the libraries works but on loading >

{message bounced because it has "$$$" in it. manually approved by list maintainer -- MM} > Date: Tue, 22 Feb 2000 13:03:35 +0100 > From: jens <jniesch at gwdg.de> > > I have trouble to install R on Sparc Sun Solaris 2.6. > make returns the error message: > Undefined symbol first referenced in file > d_lg10 ../appl/libappl.a(uncmin.o) > d_sign

I have been trying to compile R. I downloaded R-1.0.1.tgz(I think; the original tar file was untarred) and unpacked it with gzip. Now all the R files are in a directory named R-1.0.1. The source files (.c) are in R-1.0.1/src. There are files in R-1.0.1 named 'Makefile.in', 'Makeconf.in', and 'Makeconf'. I followed the instructions in INSTALL by typing

Dear list, When compiling the R-2.3.0 on FC4 x86_64, I got the following errors: make[3]: Entering directory `/project/scratch3/ligroup/wuming/src/R-2.3.0/src/main' gcc -Wl,--export-dynamic -L/usr/local/lib64 -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o

Why is it that R places CFLAGS after PKG_CFLAGS and not before when compiling a package (e.g. through R CMD build pkg)? This can be problematic if, for instance, you want to use -O3, but -O2 is in R_HOME/etc/Makeconf. If -O2 (in CFLAGS) appears after -O3 (in PKG_CFLAGS), you are left with what you didn't want: -O2. In R-exts, it says that "Flags which are set in file etc/Makeconf

Hi We are currently embedding a rather large C++ library in R (BioC), and we want some comments on the portability of how we have approach this. First of, we are not really able to do much about the portability of the basic library, which of course is the main question :) We have an approach which seems to work, I just want a bit of feedback on it.... The way we integrate it into R is

Hi This is a question prompted by the mac version of R, but as I see it, it should have broader interest. These days the CRAN Mac binary per default compiles every package for two architectures. First i386 and then ppc. In between the two compilation runs, any object files in pkgname/src is removed. This cleanup is necessary since otherwise Make would not recompile the object files

(I asked an earlier question on the rpy2 installation to the rpy2 list, the solution there was to edit the setup.py script, but this looks beyond what I can do unless someone tells me exactly what to modify). I have R 2.8.1 on 2 machines running ubuntu 8.04 (packages R-base and R-base-dev, among others, installed using Synaptic) and while the installation of rpy2 went fine on machine1, failed on

Hi. I am writing some code in C that I would like to link into R. My Makevars file is: PKG_CPPFLAGS=-I/usr/local/include PKG_LIBS=-L/usr/local/lib -lgsl PKG_CFLAGS = -Wall -O0 -g -p -pg The source file is core.c,. and I am compiling using R CMD SHLIB core.c The output is gcc -arch x86_64 -O3 -g -p -std=gnu99 -I/Library/Frameworks/ R.framework/Resources/include

Full_Name: Albrecht Gebhardt Version: 0.99.0 OS: alpha, osf4.0 Submission from: (NULL) (143.205.180.40) Im not sure if this is really correct, but it has proven to work. 1. It is always a good idea to add -std1 to DEC cc's flags to force strict ANSI language mode. It was neccessary for 0.90.x to compile, so I used it for 0.99.0 too 2. I'm not sure if -fpe3 is neccessary for DEC f77,

It is very useful to have svn version number encoded in llvm-gcc's -- version output. Here is one approach. Anyone has a better patch ? - Devang Index: Makefile.in =================================================================== --- Makefile.in (revision 53385) +++ Makefile.in (working copy) @@ -802,6 +802,9 @@ DEVPHASE_s := "\"$(if $(DEVPHASE_c),

Full_Name: W.B.Kloke Version: 1.9.1 OS: FreeBSD-5.2.1 Submission from: (NULL) (195.253.16.182) Subject line says it. I had problems installing lme4. 1. The dependency on package Matrix was not resolved (I am not sure that this is really a bug; but it is annoying, anyway). 2. Installing Matrix failed with a message saying something like "no rule for %_D.o" after compiling a lot of

Dear R Developers, For package seriation I use Fortran code. I recently got a request to add #if defined(__ICC) || defined(__INTEL_COMPILER) USE IFPORT #endif to the code since the Intel Fortran compiler otherwise has problems with rand(). However, to enable the FPP preprocessor I have to either add a compiler flag (-cpp for gFortran) which is possibly not portable or change the

I read the following in acinclude.m4: ## R_PROG_CC_FLAG_D__NO_MATH_INLINES ## --------------------------- ## In current glibc, inline version [x86] of exp is broken. ## We fix this by adding '-D__NO_MATH_INLINES' to R_XTRA_CFLAGS rather ## than AC_DEFINE(__NO_MATH_INLINES) as the former also takes care of ## compiling C code for add-on packages. Is this documented anywhere (where?), e.g.

Full_Name: Michael Hoffman Version: 2.0.0-beta-20041001 OS: OSF1 V5.1 Submission from: (NULL) (193.62.199.8) Hello. Building R 2.0.0-beta-20041001 on OSF1 V5.1 failed because the default configure sets R_XTRA_CFLAGS to "-std1 -ieee_with_inexact." The bzip2 directory includes C99 code that requires -std1 to not be set in order to compile. This halts the overall build process.

Hello, I just tried configuring R to use architecture-dependent subdirs $ r_arch=x86_64 ./configure --prefix=/u/smat/konis/testdir on a Debain Squeeze box $ uname -a Linux smapc007 2.6.32-5-686 #1 SMP Sat Sep 18 02:14:45 UTC 2010 i686 GNU/Linux After building and installing, the Rconfig.h ended up in .../lib/R/include/x86_64 but R.h still includes it as #include <Rconfig.h>

Hello, I am trying to build the R-2.11.1 software for university faculty to use in research projects on a DEC/Compaq/HP AlphaServer model GS160 16CPU/64GB memory running Tru64Unix aka OSF1 version 5.1B-5. Is it known whether it is possible to build the R-2.11.1 software on the platform I am using? In my attempts to build the R-2.11.1 software, I first used the native C and Fortran 77/90/95

Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555) (LLVM rXXXX)" Where you set the revision number? We currently use LLVM_VERSION_INFO to set this sort of information and to me it makes more sense to have the svn rev number there instead of just saying LLVM build like it does now. -Tanya On Wed, 9 Jul 2008, Devang Patel wrote: > It is very useful to have svn

Dear R users I have started to use gdb for debugging dynloaded C code as described in `Writing R Extensions'. Unfortunately I have run into several problems that I haven't been able to solve: - using `n': how comes that the same line of code appears up to three times (and inbetween the next line and maybe even the second next one?) - using `print' resp. `display': How

R fails to build with visibility on and gcc 4.9's link time optimzation, because of its practice of building part of it as archive first. Specifically it builds some bundled libraries as archive first, the symbols of which are then entirely invisible in gcc 4.9. The Matrix package also does this awful practice, with CHOLMOD.a COLAMD.a AMD.a SuiteSparse_config.a . One way of fixing R is: