Open lguangyu opened 5 years ago
Hello lguangyu,
thanks for posting your investigations so detailed since I'm running into the same problem on OpenSUSE Leap 15.2 with R 4.0.
Up until point 4 I can follow your description but then I don't understand how you examined the link call made by R CMD SHLIB
and more importantly where you removed the bare -L flag. Should I modify the src/Makevars file and remove the "-L" in the PKG_LIBS assignment?
Thanks for the help.
Oh, when looking again at the output of the R CMD INTSALL
command I can see that the link call mentioned in step 4 is included in this output on the console. So just copy and past from there and removing the bare -L flag worked. Then ldd RPostgreSQL.so
shows that libpq.so.5 has been picked up.
One additional info: When installing packages which fail during the build or test load the package is removed again. In order to keep the RPotgreSQL package even if the test load fails, I used in Rstudio:
install.packages('RPostgreSQL', INSTALL_opts=c("--no-test-load))
and then replaced the RPostgreSQL.so.
The included libpq is configured only for windows and macos. In Linux systems, you should be able to compile PostgreSQL and setup such that pg_config in the path identify the appropriate header/library locations, somewhere under your HOME directory if you don't have the root privilege.
Hi All,
In short words the
configure
script may result in illedsrc/Makevars
file with an excessive, incorrectly used-L
flag. This confusesld
and the result shared library will not be linked intolibpq.so
, causing unresolved symbol error when library is loaded.Below is the situation I find this issue:
I'm building this on a cluster server which I don't have root privilege.
dplyr
asksRPostgreSQL
but the default building process fails (missinglibpq-fe.h
); Very interestingly, I see the packages containslibpq
in the source directory, but it somewhat not attempted to build with that and simply asks for an existing build. Anyway, I tried my best to build the package against an existing PostgreSQL build (manually built from source). Though eventually I made it through (I had fair experience on the gmake system), here is the very painful process:The goal is to build against the existing build then use
-rpath
to force search forlibpq.so
in a non-standard path (I don't want to contaminate theLD_LIBRARY_PATH
and also don't want to doexport LD_LIBRARY_PATH
each time I run this package).1. Try
install.packages
with some control over configure:It fails again with same error if I didn't specify the
CFLAGS
at all. (Note, according to the cluster management the gcc I used is not in the standard path either; so I also have to specify the rpath of gcc runtime if I don't want to export it forever.)2. Manual build
Then I realized some fine control over the building process is necessary. So I manually downloaded the package and untar'd it. Run with command
It failed identically as above. It seems
CFLAGS
andLDFLAGS
were not passed toR CMD SHLIB
call, and in case if I did write something wrong R doesn't even want to complain explicitly about it as it is supposed to (like python, for example).3. Using global
Makevars
instead of per-package configureI had to try putting
CFLAGS
andLDFLAGS
into~/.R/Makevars
, then doIt finally worked on compilation and linking, but failed the load test:
This is quite a surprise when linking as
.so
succeeded while leaving symbols unresolved. Usingldd
revealed the resultRPostgreSQL.so
does not link tolibpq.so
:4. Re-call linking, identify the fault
I then examined link call made by
R CMD SHLIB
:Noticed the weird bare
-L
flag shown in the above command. I manually removed that and re-executed the command, the resultRPostgreSQL.so
now had belowldd
output:At this point I know it has to be OK. Copy this library to replace the ill version fixed the loading test failure as expected:
Investigation of the files generated by
configure
revealed the faulty-L
flag residing insrc/Makevars
. This has to be some issue with improperly designedconfigure
process.