On Thu, February 9, 2006 06:42, Chad Hogg wrote: > 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>
Sidenote: no need to include libpq-fe.h! In writing a libpqxx program you're almost completely(*) isolated from the details of libpq. (*) Fineprint: there had to be an exception, didn't there? Those are in passing connection options. Connection string format, environment variables etc. are all determined by libpq. > 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 It's odd that you're not getting errors about the library not being found, when obviously the required symbols are not being found inside it. This may be a sign of some other version of libpqxx still being installed somewhere on the system, or even the same version but compiled with a different installer. Another problem may be that you're linking to libpq first, before the linker knows that any libpq symbols are desired, and only then to libpqxx which may not have its calls to libpq resolved. You could try changing your command line to something like: g++ -o test \ `/home/cmh204/pgxxlib/pqxx-config --cflags` \ `/home/cmh204/pgxxlib/pqxx-config --libs` \ /home/cmh204/pglib/lib/ \ test.cpp Finally, there's the question of static vs. dynamic linking. You may just want to include the static version of libpqxx in your linker command line as if it were an object file: g++ -o test \ `/home/cmh204/pgxxlib/pqxx-config --cflags` \ /home/cmh204/pgxxlib/lib/libpqxx.a \ -L /home/cmh204/pglib/lib/ \ -lpq \ test.cpp > I ran nm on the library I built as well as the one that comes packaged in > Debian, and found the following differences: >< 00000008 b _ZN41_GLOBAL__N_pipeline.cxx_00000000_8FC10C9012theSeparatorE [...] >> 00000008 b _ZN54_GLOBAL__N_.._.._.._src_pipeline.cxx_00000000_58EF325712theSeparatorE If I read this right, it means that the same symbols are there but their names are being mangled differently. That's normally an indication that the two binaries have been compiled with different compilers or compiler versions--which would make them incompatible. When that sort of mismatch happens, you see exactly what we're seeing here: the linker finds the library without problems, but none of the symbols can be resolved. You could try doing a "locate libpqxx | grep -v '^/home/'" if that system is running a locate daemon, or use "find /lib /usr/lib /usr/local/ -name libpqxx\*" if it isn't. That ought to tell you if any other copies of libpqxx are installed. > 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. You've certainly researched this well! I don't think it's this problem exactly, but the solutions may be the same: upgrade to libpqxx 2.6.x and/or link to a static version of the library. Chances are one of the command lines I suggested above will resolve the problem. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
