search

radfordneal / pqR

pqR - a "pretty quick" version of R
GNU General Public License v2.0
236 stars 16 forks source link

Installation fails on Slackware 15.0 #48

Open sconti555 opened 3 years ago

sconti555 commented 3 years ago

Dear Prof Neal,

I've been trying to install your latest pqR-2020-07-23 stable version on my Slackware 14.2 (x86_64) Linux OS, but compilation fails at the 'make' stage with the following output to terminal:

make[4]: Leaving directory '/home/sc536/pqR-2020-07-23/src/library/tools'
Error in eval(do.call(substitute, list(template, list(FUN = quote(`+`))))) : 
  could not find function "do.call"
Execution halted

Below I append the outcome from running ./configure --prefix=/home/sc536/.pqR from the source directory:

R is now configured for x86_64-unknown-linux-gnu, 8-byte pointers

  Source directory:       .
  Installation directory: /home/sc536/.pqR

  C compiler:             gcc  -ffp-contract=off -g -O2
  Fortran 77 compiler:    f95  -fno-optimize-sibling-calls -fallow-argument-mismatch -ffp-contract=off -g -O2

  C++ compiler:           g++  -ffp-contract=off -g -O2
  Fortran 90/95 compiler: gfortran  -fno-optimize-sibling-calls -fallow-argument-mismatch -ffp-contract=off -g -O2
  Obj-C compiler:         gcc -g -O2 -fobjc-exceptions

  Compressed pointers:    no

  BLAS/LAPACK options:    mat_mult_with_BLAS=FALSE, BLAS_in_helpers=TRUE
                          shared BLAS: built-in, LAPACK: built-in
  External libraries:     readline, ICU, lzma
  Interfaces supported:   X11, tcltk
  Other capabilities:     PNG, JPEG, TIFF, NLS, cairo, ICU
  Other options enabled:  helper threads, task merging, R profiling, Java

  Recommended packages:   yes

I'm puzzled at the above error in that it appears to call on an R / pqR function (namely do.call()) which, to my understanding, should form part of the base pqR system I'm installing. I believe that my system, which already has a working R installation (from source), already satisfies recommended package dependencies and development libraries; of course I could be wrong...

I'd be grateful for any assistance or pointer you can provide. Many thanks in advance for your time.

radfordneal commented 3 years ago

Hi,

Yes, do.call is part of the base package. But I think the error occurs shortly after the base package was supposed to be set up, so it's possible that it indicates that base wasn't set up correctly. The error is in the code implementing the new pqR feature for arithmetic operations on lists, however, so it's possible that it's releated to that new feature.

Could you send the complete output of ./configure, eg by running this in bash in a new empty directory:

 ../pqR-2020-07-23/configure >& config.out

and the complete output of make, eg from

 make >& make.out

along with the complete set of environment variables you have set, from

set >set.out

The last is because it seems possible that the problem results from your environment somehow setting things up so that pqR looks at your existing R installation, or some such...

sconti555 commented 3 years ago

Dear Radford,

Thank you for your quick and helpful response. I should be able to provide you with the information you've requested in a couple of days, being my machine in my office (which I only get into occasionally these days).

sconti555 commented 3 years ago

Dear Radford,

You can find attached the information you've asked me about. Of note, the commands I'm issuing are ./configure --prefix=/home/sc536/.pqR and make.

make_out.txt config_out.txt set_out.txt

radfordneal commented 3 years ago

I've tried to reproduce this problem, but haven't been able to.

I installed Slackware Linux 15.0 on an old MacBook (early 2008), and then installed pqR-2020-07-23 on it, configuring it to build in the source directory, with no options, as you seem to have. It works fine. It's actually the easiest pqR build I've ever encountered, with no need to install any additional software (usually, one has to install a Fortran compiler, or the readline library, or something, but it's all there by default in Slackware 15.0).

So I'm puzzled. Some possibilities:

The make.out files that you and I got are also almost identical, up until you got an error. The set.out files have some differences, but none that would be an obvious explanation.

I've created a tar file of my build, which you can get with

wget repos.pqR-project.org/pqR-2020-07-23-built-in-place.tar.gz

I think that you should be able to run the version I built on your machine, given that your system is presumably set up with all the libraries and such in the same places (except for tex). If pqR works fine from this version I created, that would narrow down the problem to some extent. To do this, I think you'll need to create an account called 'radford', and untar the version I built in that account's home directory (it goes to pqR-2020-07-23, so be careful not to untar in the same place as your version, since it would then get wiped out). You could then run pqR from its bin directory (ie, as pqR-2020-07-23/bin/R) - it's not necessary to install pqR in order to run it.

Another thing you could try is to create a new account on your machine, and try building pqR in that account, without customizing it in any way (as you maybe have for the account you used).

Please let me know how it goes.

 Radford
sconti555 commented 3 years ago

Dear Radford,

Sincere thanks for taking your time and investigate my pqR building / installation issue.

A few thoughts of my own regarding your feedback:

I also managed to fetch your pre-build pqR tarball; however it won't work for me due to some files reported as missing:

./pqR-2020-07-23/bin/R: line 249: /home/radford/pqR-2020-07-23/etc/ldpaths: No such file or directory

Lastly, I've also attempted to configure and build (but not install) pqR from source from a fresh, uncustomised test user account as well as from root. No joy there either, as on the two occasions I hit the exact same buffer I've documented earlier.

Any further suggestion at this stage? With iterated thanks!

radfordneal commented 3 years ago

When trying to run pqR from my tarball, I think you will need to create an account called 'radford', and untar it there, as mentioned. You can see that the missing file is in /home/radford, which won't exist unless you put the tarball in an account called 'radford'.

When you run pqR (or the R core version of R, I believe) from the build directory without installing it, it assumes that some files are in the place where they were built, which was /home/radford/pqR-2020-07-23/... in this case.

sconti555 commented 3 years ago

Dear Radford,

Thank you for your clarification. I've now attempted building of your custom-compiled pqR tarball from a dedicated radford account on my machine: while the R binary executes off the tarball as wished, building from source fails nonetheless for the same reason I previously outlined. See attached log files for your reference.

What would you recommend at this stage? With sincere thanks for your continued help! out_make.txt out_configure.txt

radfordneal commented 3 years ago

Hi,

That's an interesting experiment, but not actually the one I was proposing. I was thinking of you running the build in the tarball as is, without running configure or make. It's only doing that for which one needs a 'radford' account so that the path names in the already-built version match what it was built on.

To try this, in the 'radford' account, rename the directory you built in for the experiment above to something else, and untar the tar ball again, to create a fresh pqR-2020-07-23 directory containing my build. Then, without doing anything else, do

  cd pqR-2020-07-23/bin
  ./R

and see what happens. It should run the already built version of pqR. If it does, then there's something wrong with how the build works on your machine. If it doesn't, then there's something wrong with the environment pqR runs in. It's possible that it won't run for some uninteresting reason, such as making a 'radford' account not being enough to really duplicate my setup, but we can see...

sconti555 commented 3 years ago

Hi Radford,

Apologies: I might have been unclear in my previous post.

I could successfully execute R per the code you've provided in your last message (i.e. straight from the untarred pqR-2020-07-23/bin folder). It's only after verifying this that I tried running configure + make from your custom pqR tarball, to no avail as documented in the log files I attached to my previous message.

I suppose this leaves me without much of a clue...

radfordneal commented 3 years ago

Ahh! So pqR does run on your machine, when using the version I built? Did you verify that it actually prints the pqR intro message? (Just to be sure you weren't accidentally running an installation of some other R version, rather than pqR.)

If so, that narrows down the possibilities. Could you do "gcc -v" to check what version of the compiler you're using? I compiled it with gcc 11.2.0, which is what came with the slackware installation, but perhaps you have something different. Beyond that, I'd have to think to come up with some other possibility...

sconti555 commented 3 years ago

No doubt it's pqR that successfully executed.

I should perhaps have mentioned that I'm using a (up to date) multilib flavour of Slackware current: my gcc multilib version is 11.2.0, replacing the standard gcc installation. You can refer to the Enabling multilib section of this README file to enact this change.

Of note, in the past I managed to install from source any earlier pqR version on at the time up-to-date Slackware multilib OSs.

sconti555 commented 2 years ago

Hi Radford,

I hope you've been very well since our last exchange.

Last week I performed a fresh install of the latest Slackware64 15.0 (x86_64) distribution on my system, and at the same same proceeded to installing your latest pqR 2020-07-23 stable software, without encountering any difficulty; just like you also experienced.

Reminding myself of the issues I outlined to you when installing pqR over a multilib-flavoured Slackware system, I then experimented by uninstalling pqR, enabled full multilib support, rebooted my system and tried again to install pqR from scratch. This latter attempt failed precisely as outlined in my very first post.

I am therefore inclined on thinking that pqR and multilib support have some incompatibility over a Slackware64 system. I'd be eager to hear your opinion as to this matter, with advance thanks.

radfordneal commented 2 years ago

Ah! That does narrow things down. It's odd that you say you were able to install previous versions of pqR with multilib support installed. Also intriguing that the problem seems to arise in connection with the new version's arithmetic on lists feature, though there's no obvious reason why that would introduce some new system incompatibility. Seems like there should be enough clues now to figure it out somehow, but I'd have to look into how multilib works in Slackware Linux to investigate more. I'll try to do that sometime, but won't have time for it immediately...