Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation issue with Fedora: missing -fPIC flag #1369

Closed
lepennec opened this issue Apr 15, 2020 · 30 comments
Closed

Compilation issue with Fedora: missing -fPIC flag #1369

lepennec opened this issue Apr 15, 2020 · 30 comments

Comments

@lepennec
Copy link

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
Copy link

hriebl commented Apr 15, 2020

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
Copy link
Member

edzer commented Apr 15, 2020

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
Copy link
Member

edzer commented Apr 15, 2020

@rsbivand

@zerothi
Copy link

zerothi commented Apr 15, 2020

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

@lepennec
Copy link
Author

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
Copy link

hriebl commented Apr 15, 2020

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

@zerothi
Copy link

zerothi commented Apr 15, 2020

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

@hriebl
Copy link

hriebl commented Apr 15, 2020

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

@rsbivand
Copy link
Member

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
Copy link

zerothi commented Apr 15, 2020

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
Copy link
Member

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
Copy link
Member

edzer commented Apr 15, 2020

So there is consensus to revert a37c5a0 ?

@zerothi
Copy link

zerothi commented Apr 15, 2020

Sadly, yes... :(

@rsbivand
Copy link
Member

rsbivand commented Apr 15, 2020

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.

@edzer edzer closed this as completed in 24814bd Apr 15, 2020
@hriebl
Copy link

hriebl commented Apr 15, 2020

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
Copy link
Member

edzer commented Apr 16, 2020

I think I did this in 24814bd ?

@hriebl
Copy link

hriebl commented Apr 16, 2020

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
Copy link
Member

@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
Copy link

hriebl commented Apr 16, 2020

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
Copy link

confunguido commented May 2, 2020

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
Copy link
Member

edzer commented May 2, 2020

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

@rsbivand
Copy link
Member

rsbivand commented May 2, 2020

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
Copy link

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
Copy link

hriebl commented May 2, 2020

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
Copy link
Member

edzer commented May 2, 2020

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
Copy link

hriebl commented May 2, 2020

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
Copy link

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
Copy link

Enchufa2 commented Jun 29, 2020

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 added a commit that referenced this issue Jun 29, 2020
@edzer
Copy link
Member

edzer commented Jun 29, 2020

Thanks -- like that?

@Enchufa2
Copy link

Yes, like that. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants