On Fri, 17 Dec 2004, Norman Gray wrote:
> > I've been thinking about this one today and nothing I've come up with
> > is very appealing, mostly because of the dependency problem of
> > introducing convenience libraries (SPLAT depends on NDF, so that pulls
> > in a lot of libraries, which may change from time-to-time, a problem I
> > avoid at present by using the usual linker scripts),
>
> Is this dependency problem a real problem?
>
> Given that it were possible to create a suitable library at the time
> NDF, say, were being built, and given that someone had to change that
> set of dependencies, what would they have to do. They'd have to adjust
> ndf_link and ndf_link_adam, and additionally adjust whatever bit of
> configuration it was pulled in the right libraries to the
> libndf_standalone.la library. I'd be surprised if it were impossible
> to generate those three bits of configuration from one source -- my
> first guess would be to run the output of ndf_link through some sed or
> perl script to generate the list of .la files which had to be merged
> into libndf_standalone.la.
That is just what the JNI system tends to do now. The problem I had in
mind was if I moved the build into classic, then each of the libraries
that NDF depends on would need to have convienence libraries adding to
their setups, that looked potentially messy to maintain.
> > but also because the JNI code
> > probably needs to become disjoint from STARJAVA (which means a
> > considerable amount of work and reorganisation etc.).
>
> I can see the problem here, in that you probably don't want to have
> bits of the JNI system in two places -- in java/ and libraries/.
> But...
As Mark describes, there are genuine issues with where JNI gets built,
it's not just classic code, it's also wrapped by parts best kept with the
original package.
> Adding a magic global option doesn't sound very appealing to me, and
> strikes fear into my heart at the thought of what it would do on the
> Mac.
OK, I think I've dropped that idea and have come up with a compromise one,
which still has some of the pain of understanding the NDF library
dependencies in the class tree, but nothing like as messy.
I can add statements like the following to each effected library:
libxxx_la_CFLAGS = -prefer-pic
which switches on -fPIC for the static code (using AM_CFLAGS turns out to
be a bad idea). I can also make this switchable to honour the
"--with-pic=no" option with an AM_CONDITIONAL.
I don't think there are any issues for OS X, as we have already
successfully built JNI libraries without this flag, so it looks like this
should be better (and remember this only effects static linking and all
the existing apps are now shareably linked, plus I suspect PIC code is the
default under OS X, just like on i386 Linux).
Any happier?
Cheers,
Peter.
|