On Sun, Jun 03, 2007, Anders F Björklund wrote:
> First, a small addition to the openssl.patch for "test":
> http://www.algonet.se/~afb/openpkg/openssl-addition.diff
> (originally did the same thing for "apps" for the bootstrap)
>
> However, the *reason* for the workaround is the fact that
> since OpenPKG does not provide a shared OpenSSL library,
> Darwin ld(1) will try to use the /usr/lib variant instead...
> So this will affect everything else using OpenSSL as well.
> This is noted in OpenSSL's "PROBLEMS" file, by the way.
> (file at http://cvs.openssl.org/rlog?f=openssl/PROBLEMS)
>
> There are a few workarounds to this little OS quirk:
>
> 1) change each and every (!) Makefile using OpenSSL,
> from "-lssl" to "/openpkg/lib/libssl.a" instead...
>
> 2) build shared libraries for OpenPKG's OpenSSL too.
> (this will make ld pick them up from /openpkg/lib)
>
> 3) move the system libraries aside, while building...
> (/usr/lib/libssl.dylib and /usr/lib/libcrypto.dylib,
> note that only the non-versioned developer symlinks
> are affected - not the versioned runtime libraries)
>
> I did approach 1) for OpenSSL and approach 3) for Apache,
> and then "the pitch" succeeded* in running apache+lynx. :-)
The real solution would be to _FORCE_ Mac OS X's ld(1) into prefering
the libs provided under -L _first_. It is absolutely bogus to always
prefer /usr/lib libraries over -L. I even consider this broken, although
I can image what problems the Apple people wanted to solve. So, is there
a way to _FORCE_ ld(1) to do the correct thing, i.e., search for the
paths under -L options first and /usr/lib last? Perhaps via an option or
even a small _WRAPPER_ around ld(1) which tricks it (via some LD_PRELOAD
or whatever tricks) into doing the right thing.
BTW, we do not have _any_ MacOS X boxes available at OpenPKG. So I
cannot do very much on my own on this issue, of course. If someone is
able to grant me remote access (via an unprivileged "rse" account and
SSH key authentication is fully fine) to a Mac OS X 10.4 box I can
investigate myself for us and try to find a ld(1) tricking solution.
Please contact me if someone of you can (temporarily) grant me access to
such a box.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
