[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter O'Gorman
Subject: Re: FYI: libtool--devo--1.0--patch-90
Date: Thu, 29 Jul 2004 20:55:19 +0900
User-agent: Mozilla Thunderbird 0.6 (Macintosh/20040502)

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 to and'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 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 O'Gorman -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]