Skip to content

problems compiling R packages with Linux

5 messages · Brian Ripley, Kurt Hornik, Ulf Mehlig

#
Colin Farrow <c.farrow at geology.gla.ac.uk> wrote:
> I had similar problems a few weks back. What are you using to
 > compile the fortran? I guess it is either fort77 or g77. I had
 > problems with these.  something to do with ld flags passed to
 > fort77/g77 which don't get passed on to the ld stage. I eventually
 > switched to egcs for compiling and linking and everything ran
 > smoothly.

Hello Colin,

I was using gcc and g77 2.7.3.2 and 0.5.22, respectively. My (GNU)
make is 3.76.1. I have egcs stuff on my machine, but simply putting
that directory in front of the /usr/bin directory (where "normal" gcc
lives) in PATH didn't compile completely, either. (Now "gcc -v" yielded
"egcs-2.90.27 980315/egcs-1.0.2 release".)

I have to admit, that I don't even know, what egcs -- compared to gcc
-- is ... My Linux rpm package didn't have a good description
.. which egcs version did you use?

BTW, if there are incompatibilities between gcc/gcc-egcs, maybe the
configure script should be made aware of them, shouldn't it?

-------
Further experimenting ...

... You made the observation that the problem had to do something with
switches not passed to the linker. Giving switch -shared to ld (we are
building a shared library, I think) works (invoked "manually"):

    ld -o eda.so line.o smooth.o -shared

produces eda.so (this is, where the first problem occurred). If I
start make again, it stops later at

    ../../../../bin/R SHLIB -o modreg.so bsplvd.o

Might be that R isn't invoking the linker correctly, too?

Linking modreg with ld -shared by hand seems to work, after that
R-0.63.1's Makefile produces the docs and installs; and R runs (at
least some of the demos).

Installing ctest by "R INSTALL ctest/" (my original problem) still
doesn't work, but linking .../ctest/libs/ctest.so fexact.o -shared
produces the library, and a new "R INSTALL ..." seems to install
it. So my problems seems to be solved for the moment (will start to
test the installation later), but there apparently are some
inconsistencies within R's configure/make-scripts, I think.

Many thanks for suggestions & attention!
Ulf
#
On Sat, 9 Jan 1999, Ulf Mehlig wrote:

            
[I don't think there are: the problem is what the configure script assumes
`linux' needs. Probbaly a g77/fort77 difference.]

On our Red-Hat 5.2 systems, with egcs-g77 installed, I have to set

SHLIBLDFLAGS=-shared

in config.site. It looks to me as is that is your problem too. This
is not inconsistency, just a failure to guess right. I never trust
configure scripts, so do check over these things (they are in the file
Makeconf) and override in config.site any I don't agree with.

egcs is basically a later version of gcc (which has been at 2.8.1 for
quite some time).  (Further, even the recent RH 5.2 has quite an old gcc). 
I think there are known optimization problems with egcs-1.0.2 (RH5.2 has
1.0.3a)  but I would get and use 1.10b, which seems very stable on all the
platforms we have (it is the version used to compile R on Windows, too).
#
Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote

 > On our Red-Hat 5.2 systems, with egcs-g77 installed, I have to set
 > 
 > SHLIBLDFLAGS=-shared
 > 
 > in config.site. It looks to me as is that is your problem too. This
 > is not inconsistency, just a failure to guess right. I never trust
 > configure scripts, so do check over these things (they are in the
 > file Makeconf) and override in config.site any I don't agree with.

Thank you very much! Now it works! 

I won't trust 'configure' any more ;-)   Couldn't you put this hint as
a footnote in file "INSTALL" or "PLATFORMS"? BTW, my distribution is
"DLD (Deutsche Linux Distribution)" v. 5.4, if you want to put that
in that list ...

For other beginners:

    - untar source package (e.g.: tar -vzxf R-0.63.1.tgz)
    - go to untar'ed directory
    - edit file config.site, change      

          #SHLIBLDFLAGS= 
      to
          SHLIBLDFLAGS=-shared

    - run ./configure 
    - run make
    - run make install

Thanks (for the information on compilers, too!),
Ulf
2 days later
#
Brian:  It is not very kind of you to motivate others into distrusting
my configure scripts :-)

It is also not the right approach.  Even if my time is seriously
constrained I'd prefer that configure-related problems are communicated
and fixed (by me) in the configure scripts.  Otherwise (as in our case),
eventually people ask that fixes be mentioned in the INSTALL file and/or
in the FAQ, which is not right ... (the fix can easily be coded into the
configure script, which will keep installation instructions as simple as
possible).

Currently, SHLIBLDFLAGS is determined via the XWindows configuration,
and overridden on some platforms where necessary.  The approach is not
optimal, but should work in case the standard linker is used.  In
particular, it should work on Linux/XFree86 systems.

Ulf, Brian:  Can you please try running

  grep 'SHLIBLDFLAGS' Makefile | sed 's/ *SHLIBLDFLAGS *= *//'

on your system and see what it gives?

Thanks
-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
#
Kurt Hornik <Kurt.Hornik at ci.tuwien.ac.at> wrote:
> Ulf, Brian:  Can you please try running
  > 
  >   grep 'SHLIBLDFLAGS' Makefile | sed 's/ *SHLIBLDFLAGS *= *//'
  > 
  > on your system and see what it gives?

Unfortunately, it gives nothing. There is nothing like SHLIBLDFLAGS in
Makefile (I unpacked the src-archive in a new directory and did not
change config.site for testing this). Would you like to get the whole
Makefile, or the output of configure, or something else? Does it play
a role for your configure-lookup in XWindows config files if XWindows
wasn't compiled on the machine in question? (I installed it from the
distribution's binary package; but, anyway, probably *they* compiled
their own distribution with an ±identical configuration they install
on the CDs). Just tell me what informations you need! Of course it's
better to fix the configure scripts!

Thanks,
Ulf