Re: FYI: libtool--devo--1.0--patch-90

[Peter O'Gorman]

Bob Friesenhahn wrote:

> On Wed, 28 Jul 2004, Peter O'Gorman wrote:
>
> > Gary V. Vaughan wrote:
> >
> > > Applied to HEAD.
> >
> >
> > This is failing mdemo-exec.test (after mdemo-static and mdemo-make 
> > pass) for me on Mac OS X 10.3. I don't have time to look closely right 
> > now, but it looks like it is linking the shared libdllloader.dylib and 
> > is unable to find it when executed because it is meant to be all 
> > static and it should have used a static libdllloader.a instead. This 
> > is probably somehow my fault, you just managed to expose it :)
> >
> > I'll look tomorrow.
>
>
> The mdemo-inst.test, mdemo-dryrun.test, & mdemo-inst.test tests, are 
> failing now under FreeBSD 5.0, but all tests were passing several days ago.

I had a look, but a decent solution escapes me. Gary's "obvious bug fix" 
here has the (presumably intended) effeect of adding libdlloader.la to 
libltdl.la and libltdlc.la's dependency_libs. I have no idea why it was 
passing all tests before on darwin and FreeBSD, perhaps we need to add a 
test that specifically uses libdlloader functionality (whatever that is, 
haven't looked). However, now it is there and when mdemo on darwin comes to 
build with --disable-shared, it builds all static libs in mdemo, but libltdl 
is already built, it is already built with shared libs, so there is a 
libdllloader.la that has shared libraries. libtool sees them and uses them. 
Properly so, in my opinion.

If there were a copy of libltdl under the mdemo heirarchy, this would not be 
an issue, make clean would clean it and --disable-shared would ensure that 
only the static libs got built, all would be well. Unfortunately libltdl is 
outside of mdemo's build tree and it would be bad to do a make clean in 
there :(.

If --disable-shared always preferred static libs regardless of their 
location (i.e. acted like the -static flag) then we'd be fine too. But that 
is not the intent of --disable-shared.

If we made a wrapper script even in instances where --disable-shared was 
passed to configure we'd be fine too. But --disable-shared disables building 
and libraries in the current project shared, so in the vast majority of 
cases this is unnecessary.

Anyone got any ideas?

Peter
--
Peter O'Gorman - http://www.pogma.com