[BioC] Problem loading RdbiPgSQL
Thomas Adams
Thomas.Adams at noaa.gov
Wed May 9 14:12:46 CEST 2007
Herve, Seth, & Sean,
Thanks so much for your help. My problem with loading RdbiPgSQL is now
resolved — thank goodness! I am still not completely sure what the
underlying cause of the problem was, but given with everything you had
suggested and with what I had done, I *beleive* the problem was that
RdbiPgSQL was not seeing the PostgreSQL libs due to PATH problems. What
worked for me, was logging into the server where R is installed and, as
superuser, installing RdbiPgSQL (after which, I changed permissions from
root to my own). There may be PATH issues with my user ID (and with
others on our system) which could also lead to conflicts, I suppose.
Actually, I started having install issues with all R packages utilizing
shared libraries when I started clean with the upgrade to R 2.5.0. So,
that was a pretty clear indication that I was seeing a systematic problem…
But all is resolved now and I can connect to our PostgreSQL databases
without problems. BTW, now, when I use the ldd command, I get output
much more like what you had showed me in your examples.
Thanks again for your help!
Regards,
Tom
Herve Pages wrote:
> Hi Thomas,
>
>
> Why don't you show us the output of the compilation process? When you run R CMD check on the
> RdbiPgSQL source tarball that you used for installation, it creates an RdbiPgSQL.Rcheck folder
> with an 00install.out file inside. You could compare this 00install.out file with the output
> produced by our build system here
>
> http://bioconductor.org/checkResults/2.0/RdbiPgSQL/lamb1-checksrc.html
> (scroll down to the RdbiPgSQL.Rcheck/00install.out section)
>
> In particular pay attention to this line
>
> gcc -std=gnu99 -shared -L/usr/local/lib64 -o RdbiPgSQL.so PgSQL.o PgSQLInit.o -lpq ...
>
> For most R installations there will be no "-L/home/biocbuild/bbs-2.0-bioc/R/lib -lR" part
> like we have but this is OK (this only shows up if R itself has been initially configured
> with --enable-R-shlib at built time).
> Anyway, given that your resulting RdbiPgSQL.so file is not linked against the libpq
> library, I suspect something is going wrong with the above 'gcc -shared ...' command.
>
> Let's do some basic checking:
>
> 1) On a RPM-based system like yours (Red Hat), you must have the following RPMs installed:
> postgresql
> postgresql-devel
> postgresql-libs
> Check with 'rpm -qa | grep -i postgres' and send us the output if you have some
> doubts.
>
> 2) You should be able to compile and run this "hello world" program:
>
> #include <stdio.h>
> int main() {
> printf("hello world\n");
> return 0;
> }
>
> Put this in test.c and compile with:
>
> gcc test.c -lpq
>
> You should be able to run it with ./a.out
> Now the -lpq option is not required here but it allows us to check that this executable
> has been properly linked to the libpq library (even if the test.c code doesn't use it).
> Check the links with
>
> hpages at wellington:~> ldd a.out
> linux-gate.so.1 => (0xffffe000)
> libpq.so.3 => /usr/lib/libpq.so.3 (0x40030000)
> libc.so.6 => /lib/tls/libc.so.6 (0x4004c000)
> libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40162000)
> libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x40192000)
> libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x40283000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x402be000)
> libresolv.so.2 => /lib/libresolv.so.2 (0x402f0000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x40304000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4031a000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> libdl.so.2 => /lib/libdl.so.2 (0x4032c000)
> libasn1.so.6 => /usr/lib/libasn1.so.6 (0x40330000)
> libroken.so.16 => /usr/lib/libroken.so.16 (0x40357000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x40368000)
> libdb-4.2.so => /usr/lib/tls/libdb-4.2.so (0x4036b000)
>
> Yes there are a lot! But the most important is having this line
>
> libpq.so.3 => ...
>
> If you don't have this or if you were not able to compile test.c in the first place
> with an error like
>
> hpages at wellington:~> gcc test.c -lpq
> /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../../i586-suse-linux/bin/ld: cannot find -lpq
> collect2: ld returned 1 exit status
>
> then look at the 'gcc -shared ...' command in your RdbiPgSQL.Rcheck/00install.out file,
> look for the first -L option (could be -L/usr/lib, or -L/usr/local/lib,
> or -L/usr/local/lib64, etc...), make sure that there is a libpq.so.* file (or symlink)
> in the folder specified in this -L option and try to compile test.c again with this -L option
> i.e. with something like 'gcc test.c -L/usr/local/lib -lpq' (use _your_ -L option).
> It's important to put the -L option _before_ -lpq
>
> If this doesn't work or if you end up with an a.out executable that is not properly
> linked to libpq.so.3 (the trailing number 3 could be different for you)
> then you have a PostgreSQL or gcc installation/configuration problem and you will
> need to ask your local system administrator for help.
>
>
> Cheers,
> H.
>
>
> Thomas Adams wrote:
>
>> Seth,
>>
>> Following your suggestion, I get:
>>
>> from a Linux prompt:
>>
>> ldd /awips/rep/lx/local_apps/R/lib/R/library/RdbiPgSQL/libs/RdbiPgSQL.so
>>
>> produces:
>>
>> libc.so.6 => /lib/tls/libc.so.6 (0x00329000)
>> /lib/ld-linux.so.2 (0x00a17000)
>>
>> within R:
>>
>> > system("ldd
>> /awips/rep/lx/local_apps/R/lib/R/library/RdbiPgSQL/libs/RdbiPgSQL.so")
>> libc.so.6 => /lib/tls/libc.so.6 (0x0022d000)
>> /lib/ld-linux.so.2 (0x00a17000)
>>
>> I'm guessing the "libc.so.6 =>…" line differences is suspicious…
>>
>> As far as trying installing via biocLite? I'm avoiding this route for
>> the following reason: The system I am using, where R is installed and
>> where I need it to work along with our PostgreSQL database, is in an
>> isolated network without, direct access to the internet. So, the install
>> process would be more complicated than using the biocLite install
>> script, since I would have to individually download each package, use a
>> two-step process to ftp the packages through a firewall, and install
>> them (maybe you can suggest a simple way of doing this) separately.
>>
>> Also, it may be obvious, but I have to install R in a non-standard
>> location due to our system restrictions.
>>
>> Thanks again for your help…
>>
>> Tom
>>
>>
>>
>> Seth Falcon wrote:
>>
>>> Thomas Adams <Thomas.Adams at noaa.gov> writes:
>>>
>>>
>>>
>>>> Seth,
>>>>
>>>> Thanks for your help and suggestions. Well, we have PostgreSQL 7.4.8
>>>> installed and your grep command reveals that PQfsize is in the
>>>> libpq-fe.h file located in /usr/include. In fact, when I install
>>>> RdbiPgSQL from source, it's easy to see that the build process
>>>> explicitly looks for the availability of libpq-fe.h.
>>>>
>>>>
>>> That's good. I expect RdbiPgSQL will work with 7.4.8 (not sure, but I
>>> think your problem lies elsewhere).
>>>
>>>
>>>
>>>> I do not have any control over what version of PostgreSQL we have
>>>> installed, so migrating to version 8.1.4 (or whatever) is not possible
>>>> at this time. Can anyone suggest an alternative way to install
>>>> RdbiPgSQL that circumvents this problem? Is there a Linux binary
>>>> available that I can install — will this even work?
>>>>
>>>>
>>> Did you try via biocLite? It might fail, but that failure might give
>>> us some clues.
>>>
>>> Can you look at the output of
>>>
>>> "ldd /awips/rep/lx/local_apps/R/lib/R/library/RdbiPgSQL/libs/RdbiPgSQL.so"
>>>
>>> both from the command line where you successfully built/installed
>>> RdbiPgSQL and from inside R using the system() command?
>>>
>>> + seth
>>>
>>>
>>>
>>
>
>
>
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams at noaa.gov
VOICE: 937-383-0528
FAX: 937-383-0033
More information about the Bioconductor
mailing list