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

[Eliot Miranda]

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/20100413/953aef2a/attachment.htm