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

[Eliot Miranda]

On Tue, Apr 13, 2010 at 11:03 PM, laurent laffont <laurent.laffont at gmail.com
> wrote:

>
> 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"
>

I wouldn't have thought that CFLAGS was where this belongs.  LDFLAGS or some
such.  Can you check that the libtool invocation includes  -Wl,-Bsymbolic?


> VM crashes too.
>

and what's the stack trace from gdb?


>
> 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/5721d546/attachment.htm