<br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 11:03 PM, laurent laffont <span dir="ltr"><<a href="mailto:laurent.laffont@gmail.com">laurent.laffont@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>Hi Eliot,<div><br></div><div>I've built Squeak-4.0.3.2196-src (with UUID as External). My configure command was:</div><div>../unix/cmake/configure --CFLAGS="-Wl,-Bsymbolic"</div></blockquote><div><br></div>
<div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>VM crashes too.</div></blockquote><div><br></div><div>and what's the stack trace from gdb?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br clear="all">Laurent Laffont<br>
<br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 7:20 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><div class="gmail_quote">On Mon, Apr 12, 2010 at 11:12 PM, laurent laffont <span dir="ltr"><<a href="mailto:laurent.laffont@gmail.com" target="_blank">laurent.laffont@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div>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.</div><div>
<br></div><div>So there's a real problem when UUID is external. </div></blockquote><div><br></div><div>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 ;)</div>
<div><br></div><div>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:</div><div><br></div><div><div> -Bsymbolic</div><div> When creating a shared library, bind references to global symbols</div>
<div> to the definition within the shared library, if any. Normally, it</div><div> is possible for a program linked against a shared library to over-</div><div> ride the definition within the shared library. This option is only</div>
<div> meaningful on ELF platforms which support shared libraries.</div><div><br></div><div>So when I link an external plugin I use libtool .... -Wl,-Bsymbolic ...</div><div><br></div><div>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.</div>
<div><br></div><div>HTH</div><div>Eliot</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Cheers,</div><div><br></div>Laurent Laffont<br>
<br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 1:36 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On Mon, Apr 12, 2010 at 01:48:32PM +0200, laurent laffont wrote:<br>
><br>
> I tend to think that if it's really a libuuid problem the VM would crash<br>
> whether UUIDPlugin is built Internal or External.<br>
<br>
</div>Hi Laurent,<br>
<br>
This bug is documented on Mantis<br>
<a href="http://bugs.squeak.org/view.php?id=7358" target="_blank">http://bugs.squeak.org/view.php?id=7358</a><br>
<br>
Can you confirm that the bug does *not* exist when you build the plugin<br>
as internal, and that it *does" exist if you build it external on the<br>
same platform. It would be a big help to know if this is the case.<br>
<br>
My impression up until now is that this is a bug in the runtime libuuid<br>
library, and that it has something to do with running a program with<br>
pthreads (i.e. it does not happen with a simple test program). But I<br>
have never actually seen the bug on my own system, so I'm guessing based<br>
on some google searches and the information that I read on the Pharo list.<br>
<br>
Thanks!<br>
<br>
Dave<br>
<br>
</blockquote></div><br>
<br></blockquote></div><br>
<br></blockquote></div><br></div>
<br></blockquote></div><br>