Installation fails on Slackware 15.0

[radfordneal]

Installation fails on Slackware 15.0

[radfordneal]

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]

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]

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]

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:

• Slackware 15.0 hasn't actually been released yet. I installed a "release candidate"
  version, as you presumably did too. But maybe you installed an earlier release candidate,
  with some bugs that were fixed in my version.

• Comparing the config.out files that I got and that you got, there are a few differences.
  For example, you have Java installed, and didn't, so Java will be disabled in my version.
  Also, the tex installations found were in different places, and perhaps are different. These
  don't seem like obvious sources of the problem, however.

• The processor for my old MacBook is a Core 2 Duo 2.1GHz T8100. You're probably
  using a more recent processor. But since you didn't include -march=native as a
  compiler option, gcc shouldn't be generating different code, so that doesn't seem
  to explain things.

• Building in the source directory isn't actually recommended (though it works). One
  reason is that if anything goes wrong, and you try to build again, it's possible that
  something left over from the failed attempt will affect the new attempt. So if you
  didn't do the build in a source directory that you just had unpacked from the tar
  file, that might explain the problem. (It's better to build in a different directory,
  running configure as ../src-dir/configure)

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]

Dear Radford,

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

A few thoughts of my own regarding your feedback:

• my Slackware version is synced to current, meaning that is it'd most up-to-date installation version available. Additionally, after boot I routinely upgrade installed package accordingly, meaning that my Slackware installation is as fresh as it gets.
• I agree with you that TeX and Java installation locations shouldn't be influential for pqR compilation / building purposes.
• My laptop is just over 10 years old; CPU information follows: Linux zensconti.linux.net 5.14.0 #1 SMP Sun Aug 29 22:54:53 CDT 2021 x86_64 Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz GenuineIntel GNU/Linux.
• Fair observation. Accordingly I did attempt building pqR from source in a separate directory, to no avail.

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]

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]

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]

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]

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]

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]

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]

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]

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...