• The latest stringi is in our repositories and builds fine.
• I've just tried to install stringi from CRAN in a fresh F33 container with R-devel installed and succeeded.

So there's no issue in the Makeconf provided by R-core, and the problem must be somewhere else in the configuration of your system in particular. Maybe you are using an old gcc version instead of the default one? Maybe you changed some configuration file that didn't get updated after the dist-upgrade? To check the latter, you may use rpmconf as described here.

BTW, this is not the best place for bug reports against R. For future reports, that would be Bugzilla, here.

Thanks for verifying with a fresh F33. And yes, I wasn't sure where to post my report for the attention of maintainers.

gcc is version 10.2.1 20201016.

Which configuration files would affect stringi or R package compilation? I am aware of rpmconf but did not sort out all the differences in the files yet. As mentioned, if I use the old Makeconf, which rpmconf would ask about, then it compiles. The diff shows there are several changes made, including to gcc options, with the update to F33.

Thanks for verifying with a fresh F33. And yes, I wasn't sure where to post my report for the attention of maintainers.

For any Fedora or EPEL package, RedHat's Bugzilla is the proper place.

Which configuration files would affect stringi or R package compilation?

Anything that may affect the default compilation or linking flags.

I am aware of rpmconf but did not sort out all the differences in the files yet. As mentioned, if I use the old Makeconf, which rpmconf would ask about, then it compiles. The diff shows there are several changes made, including to gcc options, with the update to F33.

Please provide the output from R CMD config --all for both Makeconf files. Also, it would help to see what's the error when the installation fails for stringi. To see that, you need to download the tarball manually from CRAN, then run R CMD INSTALL --no-clean-on-error <pkg>, and then check the logs.

R CMD config --all
With Makeconf from F32: https://paste.centos.org/view/17582142
With Makeconf from F33: https://paste.centos.org/view/0ed615e8

Even with the flag, R CMD INSTALL --no-clean-on-error stringi_1.5.3.tar.gz removes the temporary directory and thus the log is lost. This is all the output seen for the failure with the F32 Makeconf:

* installing to library ‘/home/[USER]/R/x86_64-redhat-linux-gnu-library/4.0’
* installing *source* package ‘stringi’ ...
** package ‘stringi’ successfully unpacked and MD5 sums checked
** using staged installation
checking for R_HOME... /usr/lib64/R
checking for R... /usr/lib64/R/bin/R
checking for endianness... little
checking for R >= 3.1.0 for C++11 use... yes
checking for R < 3.4.0 for CXX1X flag use... no
checking for cat... /usr/bin/cat
checking for local ICUDT_DIR... icu61/data
checking for gcc... gcc -m64
checking whether the C compiler works... no
configure: error: in `/tmp/RtmpraBjHE/R.INSTALL2cbf974b2e18b/stringi':
configure: error: C compiler cannot create executables
See `config.log' for more details
ERROR: configuration failed for package ‘stringi’

We need to see that config.log. You could play with the INSTALL flags or unpack it to run configure manually.

I don't know which INSTALL flag will not delete the temp files. So I brute forced it with a script constantly copying the temp files to another directory and got part of the config.log:

Here is the failure with the F33 Makeconf: https://paste.centos.org/view/67646cd4
Here is the success with the F32 Makeconf: https://paste.centos.org/view/4fa41aee

Unpacking the stringi tarball and running ./configure manually works regardless of which version Makeconf is in place. i.e. configure doesn't fail at "checking whether the C compiler works..."

Here's the error:

configure:2932: checking whether the C compiler works
configure:2954: gcc -m64 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fpic   -I/usr/local/include   -UDEBUG -DNDEBUG    conftest.c    >&5
lto-wrapper: fatal error: execvp: No such file or directory
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

There's an open issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1823349. Please, report there that you are experiencing this problem in Fedora 33.

And according to that report, do you have make installed? If not, installing it should solve the issue.

make is installed.

I could not reproduce the bug at https://bugzilla.redhat.com/show_bug.cgi?id=1823349 by using the example in the description:

$ echo "int main() { return 0; }" > /tmp/main.c
$ gcc /tmp/main.c -flto=2

This compiles without problems for me. Do you still think that bug is the issue in this situation?

Also, why would it fail with R CMD INSTALL but not when manually doing ./configure ?

I missed the part saying that running configure manually succeeds. That is very strange. I'm out of ideas. You need more eyes. I suggest you to open a thread in the fedora-devel mailing list.

Here's an idea: if you create a new clean user in your system and try the installation logged into that account, does it still fail?

Thanks for the idea. Yes, it still fails.

I created a new test user and the installation fails in the same way, at checking whether the C compiler works, whether installing from CRAN or the tarball.

Manually doing ./configure with the tarball works, as before.

Then the culprit is not a user config, but some system config that is different from the default one. So

• If you have any special non-default configuration under /usr/lib64/R/etc, including e.g. Rprofile, try reverting those.
• If you installed third-party stuff (e.g., to /usr/local, /opt...), check that out.

And it may be tedious, but the only way forward I see is to run rpmconf to see if something stands out as a possible culprit.

I ran rpmconf but that didn't solve the problem.

Finally found the issue! In /usr/lib64/R/etc/Renviron changing MAKE=${MAKE-'make -j16'} to MAKE=${MAKE-'make'} solves the problem. Years ago I had added -j16 to make use of multi-threading, which makes a big difference in compile times.

I still don't understand what this has to do with the different Makeconf files.

Not sure if a syntax change is needed, but maybe it's related to this comment at the top of Renviron?

As from R 4.0.0 the C code reading this follows the POSIX rules
for parameter substitution in shells, section 2.6.2 of
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18
In earlier versions ${FOO-bar} was interpreted the same as ${FOO:-bar}

I also have a file ~/.R/Makevars with contents MAKEFLAGS = -j16 which I had previously tried removing but it did not solve the error. At least it still provides a way to specify multi-threading.

Glad you solved it!