On Sat, Jun 25, 2016 at 06:13:56PM -0400, Eric S. Raymond wrote: > Hal Murray <hmur...@megapathdsl.net>: > > > > e...@thyrsus.com said: > > > 1. Apply Classic's workaround for the problem, which I don't remember the > > > details of but involved some dodgy nonstandard linker hacks done through > > > the > > > build system. *However, I did not trust this method when I understood > > > it.* > > > It seemed sure to cause porting difficulties and is inherently fragile. > > > > k...@roeckx.be said: > > > If it's the one I'm thinking about, I think the solution is to remove the > > > locking of memory. > > > > We may be confusing several bugs. > > > > There was a problem with locking stuff into memory. Some library needed by > > end of thread processing wasn't loaded yet and things worked out such that > > with the default memory 32 bit systems worked but 64 bit systems didn't > > have > > enough room. > > > > I think one solution was to create a dummy thread early on to get that > > module > > loaded. Or disable memory locking, or tell it to use more memory, or ... > > This matches what I remember, except for "use more memory". There was a third > workaround involved weird linker options to force early loading of the > library.
Like -WL,-z,now? That's not such a weird option. Kurt _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
