On Fri, 2006-03-24 at 10:50 +0100, Ralf Wildenhues wrote: > Hi Peter, > > * Peter O'Gorman wrote on Fri, Mar 24, 2006 at 01:12:22AM CET: > > On Fri, 2006-03-24 at 08:26 +0900, Peter O'Gorman wrote: > > > On Thu, 2006-03-23 at 00:29 +0900, Peter O'Gorman wrote: > > > > On Tue, 2006-03-21 at 18:11 +0100, Ralf Wildenhues wrote: > > > > > I think it should still work without prepending. > > > > > Won't that change the dlopener order on newer MAC OS X? > > > > > > > > > > This may be the same bug that Charles reported on Cygwin long ago, > > > > > that > > > > > after LoadLibrary failed dlopen was not tried? > > > Okay, we sometimes get modules that have just the originator name, and > > the end of list. In this case we should fail to open the module. > > I still haven't had time to dig through this, but: why the change to > append the dlopen loader? This change will affect all systems.
Because my darwin6 system is painfully slow. It takes a couple of hours
to run the libtool testsuite. With the dlopen module modified to APPEND
the same broken behavior is exhibited on later darwin and also linux
systems, meaning I could test faster. This modified dlopen loader
continues to pass all tests on linux and darwin8 with the modified
preload loader.
For mdemo we get one of two cases:
DF3B6004On Fri, 2006-03-24 at 10:50 +0100, Ralf Wildenhues wrote:
> Hi Peter,
>
> * Peter O'Gorman wrote on Fri, Mar 24, 2006 at 01:12:22AM CET:
> > On Fri, 2006-03-24 at 08:26 +0900, Peter O'Gorman wrote:
> > > On Thu, 2006-03-23 at 00:29 +0900, Peter O'Gorman wrote:
> > > > On Tue, 2006-03-21 at 18:11 +0100, Ralf Wildenhues wrote:
> > > > > I think it should still work without prepending.
> > > > > Won't that change the dlopener order on newer MAC OS X?
> > > > >
> > > > > This may be the same bug that Charles reported on Cygwin long ago,
> > > > > that
> > > > > after LoadLibrary failed dlopen was not tried?
>
> > Okay, we sometimes get modules that have just the originator name, and
> > the end of list. In this case we should fail to open the module.
>
> I still haven't had time to dig through this, but: why the change to
> append the dlopen loader? This change will affect all systems.
Because my darwin6 system is painfully slow. It takes a couple of hours
to run the libtool testsuite. With the dlopen module modified to APPEND
the same broken behavior is exhibited on later darwin and also linux
systems, meaning I could test faster. This modified dlopen loader
continues to pass all tests on linux and darwin8 with the modified
preload loader.
For mdemo we get one of two cases:
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { "@PROGRAM@", (void *) 0 },
{"@PROGRAM@", (void *) 0},
{"main", (void *) &main},
{"myfunc", (void *) &myfunc},
{"myvar", (void *) &myvar},
{"test_dl", (void *) &test_dl},
{"test_dlself", (void *) &test_dlself},
{0, (void *) 0}
};
or:
lt__PROGRAM__LTX_preloaded_symbols[] =
{ { "@PROGRAM@", (void *) 0 },
{0, (void *) 0}
};
Now, in the second case, I want to avoid lt_dlopen returning a found
module for the preload loader.
Why should the dlopen loader be the only one excepting preload set to
PREPEND? It makes no sense to me.
Peter
signature.asc
Description: This is a digitally signed message part
