Questions about Building libpqxx
Compilers and platforms
Can I build libpqxx with one compiler, and my own program with another, and then link the two together?
No. This is a drawback of how C++ works, or of the C-style linking process, depending on how you look at it. Generally you can't link code built with one compiler to code built with another.
Even different versions of the same compiler may differ. In the case of gcc, the 3.x and 4.x versions adhere to a standard interface that should keep object files compatible between gcc versions. There are still minor changes from time to time, however.
Can I compile libpqxx with Borland C++ Builder?
Probably. Several people have requested support for this compiler, but so far nobody has been willing to try it out and report the results.
So if you want support for this compiler to be included, just create a project file for libpqxx, throw in the source files, and see if it works. Then work with us to fix any failures until you have a working project file that can be included in the libpqxx distribution.
This is how most compilers are supported. If necessary, a script will then be written to keep the project file for the compiler up-to-date automatically.
Does it work on Solaris?
Yes, but various people have reported compilation problems. You probably won't encounter most of them, but if you do, check this list.
- Build fails after executing the command "false". We've had one case where the build procedure replaced the "ar" command with "false," resulting in a command line "false cru .libs/libpqxx.a [object files...]" Solution: Set the environment variable AR to "ar" before running configure and make.
- Link errors for system functions... One user reported needing some extra system libraries to compile libpqxx. Solution: add options "-lsocket -lnsl -lresolv" to the link command line by setting the LDFLAGS environment variable before running the configure script.
- All or some tests using large object streams crash or fail. There used to be a problem in the interaction between libpqxx's streambuf classes and some stream implementations. Solution: Upgrade libpqxx. If that doesn't work, don't use the streambuffer-based stream classes! Note that the tablestream classes are not streambuffer-based and so don't suffer from this problem.
- Unexpected end of file in Makefile. There may be a problem with the version of make you're using. Solution: try using the GNU implementation of make instead. It may already be installed on your system as gmake.
Does it work on Apple's OS X?
Yes, but it requires at least the Jaguar version of the OS (i.e., 10.2) and g++ version 3 or better. Older OS versions (including OS 9) will not work, and older compilers aren't likely to either.
Build procedure is the same as for other Unix-like platforms. If you run into problems, installing Fink may help.
Can I compile libpqxx with Sun CC (aka Sun WorkShop?)?
Yes, but apparently only with compiler versions 6.0 and up. Older versions do not support the C++ standard to the level required by libpqxx.
Some work has been done on getting a working build on version 5.1 or later of this compiler. So far this seems to require:
- Add the options "-template=wholeclass -instances=static" to the CXXFLAGS environment variable before running ./configure
- Edit libtool to pass an option '-z muldefs' to the command line that invokes ld.
You may run into other problems; please consider upgrading your compiler.
More recent versions do seem to work, such as various patch levels of "Sun WorkShop 6 update 2 C++ 5.3."
Does it work on Windows?
Yes, but it won't work very well with older Microsoft compilers. Try the Intel compiler, or if you want to use Visual C++, use version 7 or better (also known as Visual C++.NET). And naturally, ports of gcc such as MinGW will work.
If you don't have a Unix-like environment (such as Cygwin or MSYS) installed to run the configure script with, you will need to copy and possibly edit configuration headers by hand, as documented in win32/INSTALL.txt. Use the samples provided in config/sample-headers as a starting point.
Can I compile libpqxx with Microsoft Visual C++?
Yes, provided you have at least the .NET edition. Older versions won't work because of severe shortcomings in their support for the C++ standard; even the .NET versions suffer from such problems from time to time.
Makefiles for Visual C++ are bundled with the source package, although they are not maintained as actively as the rest of the project. They are generated automatically with each release, but not all changes can be automated. Some manual work besides customization may occasionally be needed. If you find that such a manual change is needed, don't forget to report the problem so it can be fixed in future versions!
Do I need libpq when I use libpqxx?
Yes; libpqxx is built on top of libpq. You call libpqxx, and libpqxx in turn calls libpq. You won't need to use or know any libpq functions yourself though.
You may get link errors about missing symbols such as _PQconnectdb, _PQfinish, _PQexec and so on; this means you need to link to libpq as well as to libpqxx.
How compatible are subsequent libpqxx versions?
There's good compile-time compatibility, but subsequent releases are generally not binary-compatible.
That means that if you link your program to libpqxx dynamically, it needs to be rebuilt whenever you upgrade the library. Unless you use a packaged version that is deliberately being kept compatible across updates, you're probably better off linking to libpqxx statically.
Why do I only get a static library when I build libpqxx? I want a dynamic library!
You should get one if you use the configure script's --enable-shared option.
There is an as-yet unresolved controversy about how dynamic libraries should be versioned (or more precisely, about how exactly the version numbering should be incorporated into the library file's name). Because of this, and because subsequent libpqxx versions are as a rule not binary-compatible anyway, building of the dynamic library is disabled by default.
Since the controversy exists at the packaging level, package managers responsible for ports of libpqxx to various platforms are encouraged to enable building of the shared library if they know that the problem does not exist on their platform.
Build problems
More solutions to typical problems can be found in the Troubleshooting FAQ. Also, try searching the mailing list archives.
A program "rmlo" fails to build. Is that bad?
Probably not. The program is a small utility for deleting large objects from a database; this may be useful for large objects created but not deleted by the libpqxx self-test programs. You're not likely to need it.
If you're using MinGW and MSYS, see win32/INSTALL.txt for instructions that may solve this problem; in a nutshell, you need to set the environment variable LDLAGS to "-lws2_32" before running the configure script. This is the most common cause of problems with rmlo.
Since rmlo is not an important part of the library, maintenance of the Makefile for this program may occassionally lag behind development of the rest of the package. This is the second-most likely cause of any problems with rmlo that you may run into.
If you still have the problem, please report it to the author. As a short-term solution, either:
- Edit tools/Makefile by hand and see what fixes the problem. In some cases it's some platform-specific library that needs to be linked in. This information will be helpful in fixing the problem at its root.
- Edit tools/Makefile and remove any references to rmlo, so that the build procedure won't attempt to compile the program.
- Create files tools/rmlo.o and tools/rmlo. It doesn't matter what's in them, or if there's anything in them at all. As long as these files exist and are newer than the rmlo.cxx source file and the library headers, the build system will conclude that there is no need to generate them anew. On a Unix-like system, just say:
touch tools/rmlo.o tools/rmlo
Any one of these should work around the problem.
Why can't the build procedure find libpq? It's in plain sight!
The libpqxx configure script finds libpq by running the pg_config script that comes with PostgreSQL. Make sure this script is in your path before running configure.
Visual C++: Debug and Release
Visual C++ likes to build both libpq and libpqxx, as well as your program, in two flavours: debug and release. When building your program in the Debug flavour, you must link to the Debug-flavoured builds of both libraries as well; when building in the Release flavour, use only the Release-flavoured libraries. The common file you edit to point the libpqxx build process at your libpq must be able to find both flavours (unless you only ever want to use one of the two flavours, of course).
When you build PostgreSQL, you get a Release-flavoured libpq binary by default. To build a Debug-flavoured libpq, re-build postgres with the DEBUG variable set:
nmake /f win32.mak DEBUG=1
Visual C++: min() and max()
This has been giving people no end of trouble. The Visual C++ compiler, by default, defines min() and max() as preprocessor macros... ˙meaning that a lot of correct, standard-conforming code will not compile properly.
The libpqxx headers disable this feature by defining the NOMINMAX preprocessor macro, which tells the Visual C++ headers not to #define min() and max(). However this seems to cause some of Visual C++'s own headers to fail to compile.
One way around this is always to include libpqxx headers before system headers, and #undef NOMINMAX between the two sets of #includes. Another workaround, suggested by Trigve Siver, is to include first the system headers and then the libpqxx headers (for older libpqxx versions that don't define NOMINIMAX it's the other way around), and finally:
#include <algorithm> #define max(x,y) std::max(x,y) #define min(x,y) std::min(x,y)
