NetBSD dagonet.omniscient.local 6.1.3 NetBSD 6.1.3 (GENERIC_HZ) #1: Sat Mar 1 19:18:46 EST 2014 met@dagonet.omniscient.local:/data/netbsd/obj/usr/src/sys/arch/i386/compile/GENERIC_HZ i386
Failure due to test programs have "Shared object "libXXX.so.X" not found"
Adding -Wl,-rpath,/usr/pkg/lib to LDFLAGS for NetBSD
The default value of libdir is (unexpanded) '${exec_prefix}/lib'. In
the non-FHS path this is fine because it only ends up in a variable
where it will be expanded later. By using this to define modulesdir
we let it slip into a define where it made no sense.
When --enable-fhs is passed to configure, we set all paths by default
in a way compliant with FHS, the Filesystem Hierarchy Standard.
http://www.pathname.com/fhs/
Each path may still be overridden by passing the specific flag for it.
Clean up the libpq autodection and make sure it functionswith both pg_config and pkg-config.
if you are installing into a non-FHS standard location such as what happens with RPMs from the Postgres yum repo, you will need to make sure pkg-config can fild the libpq.pc file.
example: export PKG_CONFIG_PATH=/usr/pgsql-9.3/lib/pkgconfig
you may also want to make sure your path can find pg_config
example: export PATH=/usr/pgsql-9.3/bin:$PATH
This commit changes behavior such that if --disable-core-odbc-support
is provided we'll build without ODBC even if the libraries are there.
Previously we would always quietly build with ODBC support if it was
on the system.
Contrary to what was said in commit 72a804983, my 2012 commit
ffc8e81b7 did not affect the behavior of --disable-core-odbc-support.
We never recognized the flag as being different from not providing the
option at all.
What the commit did do was to cause us to fail loudly if
--enable-core-odbc-support was provided but the system libraries were
not there. This behavior is preserved.
(That commit also caused us to potentially run certain checks twice,
which this commit resolves.)
You can also now provide --enable-core-odbc-support=optional which has
the same effect as the default behavior.
FS-6173 --resolve
Thanks-to: James Le Cuirot <chewi@aura-online.co.uk>
We shouldn't be using pg_config to get build options for FS from
libpq. pg_config just tells us what was used to build postgresql, not
what we should use.
See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725007
Make this optional for now until we're comfortable it works
everywhere.
FS-5821 --resolve
Brian West