Ralf S. Engelschall wrote:
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.
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.
Well, as I was considering a custom version of "cctools" for OpenPKG
anyway - I guess it could be patched to search for static libraries
the first time, instead of looking the entire path for dynamic first.
I don't know of any linker option to have it look for static libs
(other than explicitly listing them by name), but either a wrapper
to the binary or even patching the source of the binary is doable.
But OpenSSL should probably continue to have its Makefiles patched
because it's a) rather trivial and b) is used in the bootstrapping
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.
What I am investigating is to package the Darwin GCC cross-compilers for
OpenPKG use, from originals at
http://ranger.befunk.com/fink/darwin-cross/
Then you should be able to build Darwin packages (*not* Mac OS X,
but...)
as well, from your Linux or Solaris build machines using
cross-compilation ?
Unlike Apple's built-in cross-compiler, this one did use "i386" arch for
Darwin 8 instead of "i686" but it shouldn't really matter much if at
all.
The version of the tools and headers are a bit old, so they probably
need
some updating to Darwin 8.9 source that was only rather recently
released.
And I haven't used Darwin in a while, so I'm not sure if it still
works...
OpenDarwin shut down a while ago so the stand-alone Darwin OS is dead
now.
Please contact me if someone of you can (temporarily) grant me access
to
such a box.
I might be able to set up a 10.3/PPC box, but no 10.4/x86 available -
sorry.
I'll see if can get one sponsored somewhere, either existing or a Mac
Mini.
But at the moment I only have our desktop machines on the local
network...
Source code for "ld" and the other Mac OS X tools are browsable online
at
http://www.opensource.apple.com/darwinsource/DevToolsAug2006/cctools
-622.3/
but you need to use "odcctools" to get a version that actually compiles.
The Apple code is released under the Apple Public Source License v 2.0,
whose text is available online at http://www.opensource.apple.com/apsl/
--anders
______________________________________________________________________
OpenPKG http://openpkg.org
Developer Communication List [email protected]
