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