portable pgsql binary/pkg building on OSX ...

On Oct 5, 2005, at 6:34 PM, OpenMacNews wrote:

(1) to build STATIC pgsql* binaries, with NO external lib
dependencies, is
'--disable-rpath' necessary/sufficient?

I don't think so, but I'm hardly and expert here. I was able to build
psql with libq as a single executable, but in the end I found it
easier to do the standard compile and then have a script run
install_name_tool to make psql look for libq in a relative directory.

(2) i've not (yet) tried static bins on different OSX ver deployment
targets
(10.4.x, 10.3.x, etc.) and/or different CPUs (G3/G4/G5).

how portable *are* built pgsql bins? cross-compile across
platforms/cpu-families/OS's is clear, but do i need to worry abt it
for OSX
ver/cpu variants?

I don't think you have to worry about CPUs, but OS version might be a
problem. I think this is why I decided to make the second version of
pgEdit OS X 10.3 plus. If it helps you, here is what my external
dependencies for psql look like which seems to work OK on 10.3 and 10.4

otool -L psql
psql:
@executable_path/libpq.4.0.dylib (compatibility version
4.0.0, current version 4.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0,
current version 324.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 71.1.1)

When you say no external dependencies, are you really going to
include the system libraries in your package?

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi john,

is '--disable-rpath' necessary/sufficient?

I don't think so, but I'm hardly and expert here. I was able to build
psql with libq as a single executable, but in the end I found it easier
to do the standard compile and then have a script run install_name_tool
to make psql look for libq in a relative directory.

good idea/point. thx!

do i need to worry abt it for OSX ver/cpu variants?

I don't think you have to worry about CPUs, but OS version might be a
problem. I think this is why I decided to make the second version of
pgEdit OS X 10.3 plus. If it helps you, here is what my external
dependencies for psql look like which seems to work OK on 10.3 and 10.4

ok.

i suppose this will hold true except in cases where the src code itself has CPU-specificity, e.g. gmp+mpfr's (precursors to ClamAV) floating point routines have (iirc) some CPU-specific optimizations that, i'd guess, would NOT be portable ...

tho, to be honest, i haven't stumbled across anyone having issues ... need to dig a bit more. still confused :-}

otool -L psql
psql:
@executable_path/libpq.4.0.dylib (compatibility version 4.0.0,
current version 4.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0,
current version 324.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 71.1.1)

When you say no external dependencies, are you really going to include
the system libraries in your package?

not the core Apple OSX system library, per se, but 'my' replacements for some of the bundled 3rd-party stuff ...

e.g., *my* current 'psql':

/usr/local/pgsql/lib/libpq.4.dylib (compatibility version 4.0.0, current version 4.1.0)
/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.0)
/usr/local/lib/libreadline.5.0.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/local/ssl/lib/libssl.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7)
/usr/local/ssl/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.0, current version 0.9.7)
/usr/local/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0)
/usr/lib/libpam.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 365.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0)

i'm trying to learn/understand which of these get 'gathered' up into a static build, whether i need to 'manually' pkg them alongside, etc, etc.

i just have never done/worried-abt it b4 wrt trad'l F/OSS (i.e., non-OSX .apps), always simply using installed dylibs, etc.

my 'goal' it to make a "painless" & complete package to install, preferably into its own tree (within a .app, perhaps), no interfering with, or by, other installed apps/libs/headers/etc.

cheers,

richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iEYEARECAAYFAkNEfrgACgkQGnqMy4gvZ6HAQQCcCc8W3CvLIsXAWjjdwBYso8zc
u3wAniEEzferalOIAnLWohAqJQ/YYV0L
=lKkO
-----END PGP SIGNATURE-----

On Oct 5, 2005, at 9:32 PM, OpenMacNews wrote:

my 'goal' it to make a "painless" & complete package to install,
preferably into its own tree (within a .app, perhaps), no
interfering with, or by, other installed apps/libs/headers/etc.

There a couple of packages out there which may provide some useful
hints:

http://sourceforge.net/projects/pgsqlformac/
http://perso.wanadoo.fr/bruno.gaufier/xhtml/downloads.xhtml
http://www.entropy.ch/software/macosx/postgresql/

Let me know how it turns out :)

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi john

There a couple of packages out there which may provide some useful hints:

http://sourceforge.net/projects/pgsqlformac/
http://perso.wanadoo.fr/bruno.gaufier/xhtml/downloads.xhtml
http://www.entropy.ch/software/macosx/postgresql/

useful. thx! =)

Let me know how it turns out :)

will do. hopefully, howto-Q's will be welcome -- rather than simply "use _my_ pkg" responses ;-)

cheers,

richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iEYEARECAAYFAkNEiZAACgkQGnqMy4gvZ6FpGACfZXI15cxR5wf2nLWsJRA9YR/k
1FoAn0CSIzPcwLz7HvmN2s2IrtCdEMOt
=6y4Z
-----END PGP SIGNATURE-----