1) usr/src/cmd/postgres/postgresql-8.3/Makefile.sfw
a) What's the point of the "noxx-install:" target? If you accept the
fact that building libpqxx is now an integral, essential, mandatory &
dependent part of building postgres (as emphasized by the proto-fix
errors), then the target is pointless. If libpqxx must be built for the
package(s) to be successfuly created, then why build postgres without it?
b) You repeat dependencies in these 2 targets:
install: install32 install64 installxx
installxx: install32 install64
So nightly runs "make -f Makefile.sfw install" it builds install32,
install64 then installxx which repeats install32 & install64. Most
compenents (i.e. compilation) will not be repeated, but some will e.g.
the copying of files & the install-sfw scripts (which often produce
errors if run more than once).
Even if this doesn't lead to errors/warnings it is a waste of cycles,
and can potentialy lead to endless loops. You need a better target
hierarchy.
Again, if you accept that libpqxx is now an integral part of building
postgres, then the following is better:
install: installxx
installxx: install32 install64
2) /usr/postgres/8.3/lib/libpqxx-2.6.9.so (32bit and 64bit)
If I run ldd on this library in your proto area, it fails to satisfy the
dependency on libpq.so.5:
$ ldd libpqxx-2.6.9.so
libpq.so.5 => (file not found)
libCstd.so.1 => /usr/lib/libCstd.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libc.so.1 => /lib/libc.so.1
/usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
This is because the RUNPATH does not include /usr/postgres/8.3/lib when
it's built:
$ elfdump libpqxx-2.6.9.so |grep RUNPATH
[7] RUNPATH 0x12607
/ws/onnv-tools/SUNWspro/SS11/lib/rw7:/ws/onnv-tools/SUNWspro/SS11/lib/v8plus:/ws/onnv-tools/SUNWspro/SS11/lib:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib
As a result, this library can't be used by customers without them first
declaring LD_LIBRARY_PATH (something they shouldn't have to do when
using our products).
Look at one of the other postgres libraries as an example:
$ ldd libecpg.so | grep libpq
libpq.so.5 => /usr/postgres/8.3/lib/libpq.so.5
$ elfdump libecpg.so | grep RUNPATH
[7] RUNPATH 0xd4f
/usr/sfw/lib:/usr/postgres/8.3/lib
In fact, the RUNPATH associated with libpqxx-2.6.9.so is a mess! Why
does it contain all those directories specific to our build machines?
I think you need to tweak the LD_OPTIONS in
usr/src/cmd/postgres/postgresql-8.3/libpqxx/Makefile.sfw
Bjorn Munch wrote:
> I have now created a new webrev. I have moved the libpqxx directory
> under usr/src/cmd/postgres/postgresql-8.3 and do the build there as
> part of the postgresql-8.3 build.
>
> It should be possible to build libpqq also as part of 8.4 by creating
> a softlink; the PGMAJVER variable will direct where it gets installed
> and where it gets libpq from.
>
> The build target noxx-install is meant for building manually without
> libpqxx, e.g. when building for upload to postgresql.org.
>
> I have also addressed some of Jim's comments about the packages.
>
> New webrev in the same location as the old one:
>
> http://cr.opensolaris.org/~bjornmu/pqxx-webrev/
>
> nightly is currently running.
>
> NB I'm away from Thursday morning, will be back Monday.
>
> - Bjorn
