[Vm-dev] Re: UUID as internal (was 22.214.171.1246 for Unix)
laurent.laffont at gmail.com
Wed Apr 14 06:03:25 UTC 2010
I've built Squeak-126.96.36.1996-src (with UUID as External). My configure
VM crashes too.
On Tue, Apr 13, 2010 at 7:20 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
> On Mon, Apr 12, 2010 at 11:12 PM, laurent laffont <
> laurent.laffont at gmail.com> wrote:
>> I have just built last release (Squeak-188.8.131.520-src.tar.gz) with UUID as
>> internal and it works like a charm. All Pharo 1.0-RC4 tests green ! Thank
>> you all.
>> So there's a real problem when UUID is external.
> Has anybody looked at the issue of symbol scope in linux as being a
> possible cause here? The default linux binding rules are that symbols in
> libraries are process-wide and the first loaded definition of a symbol is
> used in all subsequent library loads to resolve references. The result is
> that if, say, one links an external plugin against some utility code that
> also exists in the VM, then on loading the external plugin its references to
> the utility code will be resolved to the definitions in the VM, not its own
> copy. This may be fine until you have two external plugins linked against
> utility libraries that expect to have their own copies of that utility code.
> When the second external plugin is loaded it gets linked against the first
> plugin's utility code and they end up sharing one copy which can cause
> confusion and delay ;)
> In Cog on linux for external plugins I use the -Bsymbolic link flag to
> override the default binding rule. This form the ld man page:
> When creating a shared library, bind references to global
> to the definition within the shared library, if any. Normally,
> is possible for a program linked against a shared library to
> ride the definition within the shared library. This option is
> meaningful on ELF platforms which support shared libraries.
> So when I link an external plugin I use libtool .... -Wl,-Bsymbolic ...
> If this looks at all relevant then could someone who has a system on which
> the external UUID plugin fails, try rebuilding the external plugin using the
> -Wl,-Bsymbolic flag and see if it fixes things? I'm imagining that the
> symbol visiblity rules could affect whether variables used in the uuid seed
> are shared or not or initialized or not, etc.
>> Laurent Laffont
>> On Tue, Apr 13, 2010 at 1:36 AM, David T. Lewis <lewis at mail.msen.com>wrote:
>>> On Mon, Apr 12, 2010 at 01:48:32PM +0200, laurent laffont wrote:
>>> > I tend to think that if it's really a libuuid problem the VM would
>>> > whether UUIDPlugin is built Internal or External.
>>> Hi Laurent,
>>> This bug is documented on Mantis
>>> Can you confirm that the bug does *not* exist when you build the plugin
>>> as internal, and that it *does" exist if you build it external on the
>>> same platform. It would be a big help to know if this is the case.
>>> My impression up until now is that this is a bug in the runtime libuuid
>>> library, and that it has something to do with running a program with
>>> pthreads (i.e. it does not happen with a simple test program). But I
>>> have never actually seen the bug on my own system, so I'm guessing based
>>> on some google searches and the information that I read on the Pharo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev