[Vm-dev] Re: UUID as internal (was 4.0.3.2196 for Unix)

laurent laffont laurent.laffont at gmail.com
Wed Apr 14 06:03:25 UTC 2010


Hi Eliot,

I've built Squeak-4.0.3.2196-src (with UUID as External). My configure
command was:
../unix/cmake/configure --CFLAGS="-Wl,-Bsymbolic"

VM crashes too.

Laurent Laffont


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-4.0.3.2200-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:
>
>        -Bsymbolic
>            When creating a shared library, bind references to  global
>  symbols
>            to  the definition within the shared library, if any.  Normally,
> it
>            is possible for a program linked against a shared library to
>  over-
>            ride the definition within the shared library.  This option is
> only
>            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.
>
> HTH
> Eliot
>
>
>> Cheers,
>>
>> 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
>>> crash
>>> > whether UUIDPlugin is built Internal or External.
>>>
>>> Hi Laurent,
>>>
>>> This bug is documented on Mantis
>>>  http://bugs.squeak.org/view.php?id=7358
>>>
>>> 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
>>> list.
>>>
>>> Thanks!
>>>
>>> Dave
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100414/2ad1cef2/attachment-0001.htm


More information about the Vm-dev mailing list