Compilation issue with Fedora: missing -fPIC flag

[lepennec]

The latest sf version does not compile under fedora: configure yields

checking GDAL: linking with --libs only... yes
checking GDAL: /usr/share/gdal/pcs.csv readable... yes
checking GDAL: checking whether PROJ is available for linking:... no
/usr/bin/ld: /tmp/ccJ892zj.o: relocation R_X86_64_32 against symbol `__gxx_personality_v0@@CXXABI_1.3' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
configure: Install failure: compilation and/or linkage problems.
configure: error: cannot link projection code

Using the PIC version of the FLAGS with R Config solves the issue.
See PR: #1368

[hriebl]

I just had the same issue. It is caused by commit a37c5a0. Reverting this commit fixes the compilation on Fedora, so I am not sure whether adding the -fPIC flag is the right approach here...

[edzer]

Looks like CRAN fedora didn't have an issue with it; please discuss with @zerothi and #1291 how to proceed in a way that doesn't break my next submission to CRAN.

[edzer]

@rsbivand

[zerothi]

Perhaps moving LDFLAGS to the end of the line is the better approach. Could you show your LDFLAGS?

[lepennec]

Here is the result on my computer

# R CMD config LDFLAGS
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

[hriebl]

Same here on the current Fedora beta, i.e. on Fedora 32.

[zerothi]

Could you try and move a37c5a0 LDFLAGS to the end of the line and try again

[hriebl]

Doesn't seem to work for me... Same error as posted above.

[rsbivand]

My LDFLAGS on a locally built R from source:
$ R CMD config LDFLAGS -L/usr/local/lib64
The value may vary depending on the R installation. @lepennec has the R rpm; my rpm R:
$ /usr/bin/R CMD config LDFLAGS -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

I can reproduce the problem with the Fedora R rpm. Changing the position does not help. Probably must trap the configure.vars= value, then trap the actual value returned by R CMD config, and use the configure.vars= value. Really the original fix was unfortunate, as LD_LIBRARY_PATH would have been better, because that is what was meant.

As things stand, sf from CRAN (0.9-2) cannot be installed using the Fedora R rpm. The rpm LDFLAGS is hardwired.

Where in configure.ac is LDFLAGS detected - is it set as it were prior to running ./configure and then forgotten?

[zerothi]

LDFLAGS is detected here : ${LDFLAGS=`"${RBIN}" CMD config LDFLAGS`}

The problem is that Fedora sets -pie which does not allow -static or -fpic code.
See here.

Seems like a recurring problem for Fedora... :(
There is a fix, but wasn't committed.

I see no other way than to revert, unless you want to detect specs in configure... :(

[rsbivand]

Yes, reverting seems sensible, given the immediate reaction. Shame there is no test framework for this, maybe a Fedora R rpm user on this issue should volunteer to test pre-release candidates.

[edzer]

So there is consensus to revert a37c5a0 ?

[zerothi]

Sadly, yes... :(

[rsbivand]

For those stuck until the reversion is published, and are using the R rpm, it looks as though setting LDFLAGS= ./configure works when ./configure fails. So from the command line R CMD INSTALL -l baretull sf_0.9-2.tar.gz fails but LDFLAGS= R CMD INSTALL -l baretull sf_0.9-2.tar.gz gets past the problem in ./configure.

[hriebl]

Yes, reverting seems sensible, given the immediate reaction. Shame there is no test framework for this, maybe a Fedora R rpm user on this issue should volunteer to test pre-release candidates.

I could certainly do this. How do I know when you are preparing a new release for CRAN?

[edzer]

I think I did this in 24814bd ?

[hriebl]

Sure, you fixed this issue. I was just offering in general to test your pre-release candidates on Fedora, as Roger proposed, in case there's any need for that.

[rsbivand]

@hriebl Thanks! All testing before submissions go to CRAN is very helpful, but we don't have a mechanism (I think) to say when an RC (release candidate) is ready to be checked. The easiest way is to download an RC tarball, and run R CMD check at the command line, and report back as good to go, minor issues, or show-stopper. Github tries to internalise this with CI, but it is difficult to cover all angles. If we went to (r-spatial/discuss#37) OSGeo-style PSC RC handling, we could put a system in place for staged RC tarball publication prior to CRAN submission, but we are not there yet.

[hriebl]

Thank you, @rsbivand! How about, for the time being, you set up a mailing list for RC testers and ask them to check whether the current master branch still compiles on their systems a couple of days before submitting to CRAN?

[confunguido]

Not sure if this is the right issue. Definitely the same as #1379 I can't get the sf package to install on Fedora 32. Keep getting the error:

checking PROJ: checking whether PROJ and sqlite3 are available for linking:... no
configure: error: libproj not found in standard or given locations.
ERROR: configuration failed for package ‘sf’

Maybe I'm not understanding the proposed solution:

For those stuck until the reversion is published, and are using the R rpm, it looks as though setting LDFLAGS= ./configure works when ./configure fails. So from the command line R CMD INSTALL -l baretull sf_0.9-2.tar.gz fails but LDFLAGS= R CMD INSTALL -l baretull sf_0.9-2.tar.gz gets past the problem in ./configure.

Is there anything I'm missing in this command LDFLAGS= R CMD INSTALL -l baretull sf_0.9-2.tar.gz?

[edzer]

Maybe setting LDFLAGS to an actual value? Have you tried installing sf from github master?

[rsbivand]

Before 24814bd, LDFLAGS needed to be set empty for me, to override the RPM values. I do suggest dropping the RPMs completely if they do not work for you, simply (?) install R, PROJ and GDAL from source, but use RPMs for GDAL upstream dependencies. Best try to install from github, as LDFLAGS= has been dropped there.

[confunguido]

Before 24814bd, LDFLAGS needed to be set empty for me, to override the RPM values. I do suggest dropping the RPMs completely if they do not work for you, simply (?) install R, PROJ and GDAL from source, but use RPMs for GDAL upstream dependencies. Best try to install from github, as LDFLAGS= has been dropped there.

This worked!! Thanks a lot. I installed PROJ and R from source and gdal from rpm. Then, iInstalling from github worked fine. Thanks!

[hriebl]

Not sure if this is the right issue. Definitely the same as #1379 I can't get the sf package to install on Fedora 32. Keep getting the error:

checking PROJ: checking whether PROJ and sqlite3 are available for linking:... no
configure: error: libproj not found in standard or given locations.
ERROR: configuration failed for package ‘sf’

Maybe I'm not understanding the proposed solution:

For those stuck until the reversion is published, and are using the R rpm, it looks as though setting LDFLAGS= ./configure works when ./configure fails. So from the command line R CMD INSTALL -l baretull sf_0.9-2.tar.gz fails but LDFLAGS= R CMD INSTALL -l baretull sf_0.9-2.tar.gz gets past the problem in ./configure.

Is there anything I'm missing in this command LDFLAGS= R CMD INSTALL -l baretull sf_0.9-2.tar.gz?

For the sake of completeness: I had the same error on F32 and solved it with sudo dnf install sqlite-devel instead of compiling R, PROJ, or GDAL from source (which might not be a convenient solution for most people). After that, either install sf from GitHub or unset the LDFLAGS and install sf from CRAN.

[edzer]

That sounds like the more attractive recipe. Shall I add that to the README.md section? I do indeed believe that for compiling sf sources we don't need sqlite-devel, but for doing the tests in configure we do. That is also something to reconsider!

[hriebl]

I would say yes. Apparently sqlite-devel was not required before F32, but F32 was released on Tuesday, so people are going to stumble over this more and more often. Also, the error message is weird, because it suggests that PROJ is missing rather than SQLite...

[ScottStetkiewicz]

For the sake of completeness: I had the same error on F32 and solved it with sudo dnf install sqlite-devel instead of compiling R, PROJ, or GDAL from source (which might not be a convenient solution for most people). After that, either install sf from GitHub or unset the LDFLAGS and install sf from CRAN.

Can confirm hriebl's workaround using sqlite-devel worked for me after updating to F32

[Enchufa2]

I arrive here via a report by @rsbivand for rgdal in the R-SIG-Fedora mailing list. The issue in this case (as it is now in rgdal) was that CXXFLAGS="${R_HOME}/bin/R" CMD config CXXFLAGS` (as indicated in Writing R Extensions) is missing in the configure script. Note that CPPFLAGS are not the same as CXXFLAGS (a common mistake).

[edzer]

Thanks -- like that?

[Enchufa2]

Yes, like that. :)