Re: portable pgsql binary/pkg building on OSX ...

-----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-----