[RFC] Fixing OS X static builds in 1.4.x/trunk

So I've been trying to work out how to fix the OS X static builds for 1.4.0.

The problem is that:

* Keychain support in libsvn_subr requires us to link to external
  OS X libraries.

* That linkage must be made via a -framework option to gcc, and not the
  usual -llibrary (though as I understand it, the result is similar).

* libtool 1.5.x doesn't record dependencies for libraries linked via
  -framework. (libtool 2.0 does, but that doesn't help us. It appears
  that the support won't be ported back to the 1.5 branch.)

What this means is that, because we only have the external library
'keychain' listed as being used by libsvn_subr in build.conf, a static
link ('configure --disable-shared) of any of the executables that uses
libsvn_subr(simple_provider.o) fails because the -framework line isn't
passed as required [1].

I can think of two ways to fix this:

1. Add 'keychain' as a dependency to all the executables in build.conf
   that require it. That's quite a lot, and none of those executables
   really depend on keychain.

2. Add the contents of SVN_KEYCHAIN_LIBS to LIBS and remove all traces
   of keychain from build.conf. This means that the -framework option
   will be passed to all link lines, presumably solving the problem.

We had a brief discussion on IRC about this a day or so ago. At that
time, I was suggesting #1, but I now much prefer #2 - it is a hack,
but it's localised and we can identify it at such.

Max asked if there was a way we could conditionalise support in a better
way - perhaps by fixing the build generator to generate transitive
dependencies in this case. Modifying the build generator is way beyond
my capability though, so someone else would need to pick this up.

Assuming #2 works (I can't test right now), I'd like to commit and
propose for backport to 1.4.x - does anyone have any other objections
or suggestions?

Regards,
Malcolm

[1] As it happens, linking the 'svn' executable _does_ work because keychain
    is listed as a direct dependency, but that's not correct.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 12:36:13 2006