-----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-----
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
