I would now like to build a project that uses libpqxx on another machine with a different architecture and for which I do not have administrator access to install packages.
I have followed the following steps:
<download, unzip, untar postgresql source>
cd postgresql-7.4.7/
./configure --prefix=/home/cmh204/pglib/
gmake
gmake src/bin install
gmake src/include install
gmake src/interfaces install
gmake docs install
cd ../libpqxx-2.5.5/
./configure --prefix=/home/cmh204/pgxxlib/ PG_CONFIG=/home/cmh204/pglib/bin/pg_config
gmake
gmake install
At this point, it seems that the library has successfully built.
Then I try building my program that links to it.
As an example, here is a simple program:
#include <libpq-fe.h>
#include <pqxx/pqxx>
int main( int argc, char* argv[] )
{
PGconn * conn = PQconnectdb( "blah" );
pqxx::connection c;
return 0;
}
And here is the Makefile:
test : test.cpp
g++ -o test \
-I /home/cmh204/pglib/include/ \
-I /home/cmh204/pgxxlib/include/ \
-L /home/cmh204/pglib/lib/ \
-L /home/cmh204/pgxxlib/lib/ \
-Wl,--rpath -Wl,/home/cmh204/pgxxlib/lib/ \
-lpq -lpqxx \
test.cpp
At the linking stage, I receive these errors:
/tmp/ccHFc6e4.o(.text+0x72): In function `main':
: undefined reference to `pqxx::connection::connection[in-charge]()'
/tmp/ccHFc6e4.o(.text+0x92): In function `main':
: undefined reference to `pqxx::connection::~connection [in-charge]()'
collect2: ld returned 1 exit status
With a program that actually uses the libpqxx calls there are many more errors. With a program that uses only libpq calls, there are none. I have tried this with nearly every combination of postgresql and libpqxx version available, and they all seem to have the same results.
I found the following in the output of running make install on the libpqxx source:
----------------------------------------------------------------------
Libraries have been installed in:
/home/cmh204/pgxxlib//lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
(This is why I added the seventh line to my Makefile.)
I ran nm on the library I built as well as the one that comes packaged in Debian, and found the following differences:
719,721d718
< 00000008 b _ZN41_GLOBAL__N_pipeline.cxx_00000000_8FC10C9012theSeparatorE
< 00000000 b _ZN41_GLOBAL__N_pipeline.cxx_00000000_8FC10C9013theDummyQueryE
< 00000004 b _ZN41_GLOBAL__N_pipeline.cxx_00000000_8FC10C9013theDummyValueE
749a747,749
> 00000008 b _ZN54_GLOBAL__N_.._.._.._src_pipeline.cxx_00000000_58EF325712theSep
aratorE
> 00000000 b _ZN54_GLOBAL__N_.._.._.._src_pipeline.cxx_00000000_58EF325713theDum
myQueryE
> 00000004 b _ZN54_GLOBAL__N_.._.._.._src_pipeline.cxx_00000000_58EF325713theDum
myValueE
1305,1308d1304
< 00002ef0 T _ZN37_GLOBAL__N_util.cxx_00000000_1108B58212libpq_escapeEPKcj
< 00000000 W _ZN37_GLOBAL__N_util.cxx_00000000_1108B58217from_string_floatIdEEvP
KcRT_
< 00000000 W _ZN37_GLOBAL__N_util.cxx_00000000_1108B58217from_string_floatIeEEvP
KcRT_
< 00000000 W _ZN37_GLOBAL__N_util.cxx_00000000_1108B58217from_string_floatIfEEvP
KcRT_
1342a1339,1342
> 00002ef0 T _ZN50_GLOBAL__N_.._.._.._src_util.cxx_00000000_EF2233B112libpq_esca
peEPKcj
> 00000000 W _ZN50_GLOBAL__N_.._.._.._src_util.cxx_00000000_EF2233B117from_strin
g_floatIdEEvPKcRT_
> 00000000 W _ZN50_GLOBAL__N_.._.._.._src_util.cxx_00000000_EF2233B117from_strin
g_floatIeEEvPKcRT_
> 00000000 W _ZN50_GLOBAL__N_.._.._.._src_util.cxx_00000000_EF2233B117from_strin
g_floatIfEEvPKcRT_
Unfortunately, I do not know how to interpret these differences.
I thought my problem might be related to the one discussed in http://gborg.postgresql.org/pipermail/libpqxx-general/2005-December/001070.html, but the solution proposed there simply moved the errors from link-time to run-time.
If anyone could help me, I would be very appreciative.
Thank you,
Chad Hogg
(Sorry about the long post; I thought it would be best to provide as much information as I can think of up front.)
_______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
