[EMAIL PROTECTED] wrote: > Yeah, we have seen this before on various platforms. On some, > LD_LIBRARY_PATH isn't actually anything the dynamic linker pays > attention to, and on others, it is trumped by the installation rpath > built into the executables. Not putting an rpath into the executables > would make life better for "make check" at the cost of making the > executables much more fragile in actual use. I don't see a good > solution :-( but if you do, step right up to the plate ...
Well, I'm not going to be the one who suggests that adding: export LD_PRELOAD=$libdir/libpq.so to pg_regress.sh before the initdb command will fix it (on Linux). Because the more I think about it, the less I like the idea of "make check" as a way to validate PostgreSQL. Not only because it looks like some of us may have actually been testing a hybrid "new programs/old libraries" combination, but because "make check" uses a temporary installation. For acceptance testing, I want to know that it was built and installed properly, so I'll have to use "make installcheck" after installation. (Say, why isn't this listed in INSTALL anymore?) ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org