Re: HEAD fails mdemo-exec on darwin6 (Mac OS X 10.2)

[Peter O'Gorman]

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