My compliments on another great answer Jeroen! I also agree that Chad researched and analyzed the problem very well!
I agree to link with the static libpqxx in this case, much simpler than trying to setup dynamic runtime linking. Very keen eye to notice the "-lpqxx -lpq" out of order. Since Chad was building on a non-Debian machine, wouldn't we expect to see different name mangling (or at least not be surprised because of the high probability of using a different compiler version)? By the same token (pun unintended), a valuable exercise might be, using the nm command, to match the undefined symbols from the application against the defined symbols from the libpqxx libraries. Overall I'm very impressed with the libpqxx library and see some possibly great uses for it in some of my projects! It has been easy to integrate into existing C++/stl/boost-based software on both Windows and GNU/Linux. A great c++ interface to a great dbms. Thanks! -Rob Jeroen T. Vermeulen wrote: > 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
