Thread: portable pgsql binary/pkg building on OSX ...
hi all, i've been happily building runing ver's of pgsql (current 81b2) on my OSX 10.4.2 on G4 boxes. to date, always linked/built to my /usr/local dev tree of libs, headers, etc. now, i'd like to build once, pkg and deploy to other boxes. admittedly, dylibs/libtool/etc which have been standard fare in my per-box builds, now have me a mite concerned/confused. soooo, a couple of Q's b4 i begin appropriate 'thrashing': (1) to build STATIC pgsql* binaries, with NO external lib dependencies, is '--disable-rpath' necessary/sufficient? iiuc '--disable-shared' simply defines whether/not the dylibs are built, but is irrelevant to the bins ... (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? thx, richard
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 (precursorsto 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 themalongside, 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), nointerfering 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-----