Problems with CogVM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with CogVM

CdAB63
I'm usually running squeak using stackVM (which I compiled to suit my
needs). But I just crashed against an old problem. Yesterday I gave
Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
and this system is a ... about gcc -m32, I either use the cogvm that
comes along the distribution or I select one pre-built from Elliot.
Unecessary to say that I had all sorts of problems with NativeBoost not
being able to call the foreign libraries...

Then I decided to come back and try squeak with cogvm and I tried to
suit it to run OpenGL but it fails. I think it's impossible that I'm the
only poor mortal to have ever faced the problem of suiting FFI to
properly run Cog in a x86_64 architecture. Have someone dealt with this
problem???

PS: I did all the tricks with LD_LIBRARY_PATH, ld.conf.so.d, etc.

CdAB

Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

Igor Stasenko
On 28 November 2012 21:55, Casimiro de Almeida Barreto
<[hidden email]> wrote:
> I'm usually running squeak using stackVM (which I compiled to suit my
> needs). But I just crashed against an old problem. Yesterday I gave
> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
> and this system is a ... about gcc -m32, I either use the cogvm that
> comes along the distribution or I select one pre-built from Elliot.
> Unecessary to say that I had all sorts of problems with NativeBoost not
> being able to call the foreign libraries...

NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
don't have NB plugin and some small changes to VM itself to support
native code in 'NB' way.

>
> Then I decided to come back and try squeak with cogvm and I tried to
> suit it to run OpenGL but it fails. I think it's impossible that I'm the
> only poor mortal to have ever faced the problem of suiting FFI to
> properly run Cog in a x86_64 architecture. Have someone dealt with this
> problem???

All Cog VMs are 32-bit.  That means that you can link dynamically only
with 32-bit libraries.


>
> PS: I did all the tricks with LD_LIBRARY_PATH, ld.conf.so.d, etc.
>
> CdAB
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

CdAB63
On 28-11-2012 19:05, Igor Stasenko wrote:

> On 28 November 2012 21:55, Casimiro de Almeida Barreto
> <[hidden email]> wrote:
>> I'm usually running squeak using stackVM (which I compiled to suit my
>> needs). But I just crashed against an old problem. Yesterday I gave
>> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
>> and this system is a ... about gcc -m32, I either use the cogvm that
>> comes along the distribution or I select one pre-built from Elliot.
>> Unecessary to say that I had all sorts of problems with NativeBoost not
>> being able to call the foreign libraries...
> NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
> don't have NB plugin and some small changes to VM itself to support
> native code in 'NB' way.
In Pharo I use Jenkins integrated cogvm with NB.
>
>> Then I decided to come back and try squeak with cogvm and I tried to
>> suit it to run OpenGL but it fails. I think it's impossible that I'm the
>> only poor mortal to have ever faced the problem of suiting FFI to
>> properly run Cog in a x86_64 architecture. Have someone dealt with this
>> problem???
> All Cog VMs are 32-bit.  That means that you can link dynamically only
> with 32-bit libraries.
>
I have all 32-bit libraries. System should work.
>> PS: I did all the tricks with LD_LIBRARY_PATH, ld.conf.so.d, etc.
>>
>> CdAB
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

Igor Stasenko
On 28 November 2012 22:07, Casimiro de Almeida Barreto
<[hidden email]> wrote:

> On 28-11-2012 19:05, Igor Stasenko wrote:
>> On 28 November 2012 21:55, Casimiro de Almeida Barreto
>> <[hidden email]> wrote:
>>> I'm usually running squeak using stackVM (which I compiled to suit my
>>> needs). But I just crashed against an old problem. Yesterday I gave
>>> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
>>> and this system is a ... about gcc -m32, I either use the cogvm that
>>> comes along the distribution or I select one pre-built from Elliot.
>>> Unecessary to say that I had all sorts of problems with NativeBoost not
>>> being able to call the foreign libraries...
>> NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
>> don't have NB plugin and some small changes to VM itself to support
>> native code in 'NB' way.
> In Pharo I use Jenkins integrated cogvm with NB.

ah.. ok. Just had to say in case if you unaware of it.

>>
>>> Then I decided to come back and try squeak with cogvm and I tried to
>>> suit it to run OpenGL but it fails. I think it's impossible that I'm the
>>> only poor mortal to have ever faced the problem of suiting FFI to
>>> properly run Cog in a x86_64 architecture. Have someone dealt with this
>>> problem???
>> All Cog VMs are 32-bit.  That means that you can link dynamically only
>> with 32-bit libraries.
>>
> I have all 32-bit libraries. System should work.

Try starting VM using ptrace to see where/what it tries to load and
why it failing.

--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

CdAB63
On 28-11-2012 19:18, Igor Stasenko wrote:

> On 28 November 2012 22:07, Casimiro de Almeida Barreto
> <[hidden email]> wrote:
>> On 28-11-2012 19:05, Igor Stasenko wrote:
>>> On 28 November 2012 21:55, Casimiro de Almeida Barreto
>>> <[hidden email]> wrote:
>>>> I'm usually running squeak using stackVM (which I compiled to suit my
>>>> needs). But I just crashed against an old problem. Yesterday I gave
>>>> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
>>>> and this system is a ... about gcc -m32, I either use the cogvm that
>>>> comes along the distribution or I select one pre-built from Elliot.
>>>> Unecessary to say that I had all sorts of problems with NativeBoost not
>>>> being able to call the foreign libraries...
>>> NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
>>> don't have NB plugin and some small changes to VM itself to support
>>> native code in 'NB' way.
>> In Pharo I use Jenkins integrated cogvm with NB.
> ah.. ok. Just had to say in case if you unaware of it.
>
>>>> Then I decided to come back and try squeak with cogvm and I tried to
>>>> suit it to run OpenGL but it fails. I think it's impossible that I'm the
>>>> only poor mortal to have ever faced the problem of suiting FFI to
>>>> properly run Cog in a x86_64 architecture. Have someone dealt with this
>>>> problem???
>>> All Cog VMs are 32-bit.  That means that you can link dynamically only
>>> with 32-bit libraries.
>>>
>> I have all 32-bit libraries. System should work.
> Try starting VM using ptrace to see where/what it tries to load and
> why it failing.
>
I've attached the error log...



SqueakDebug.log (17K) Download Attachment
signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

Igor Stasenko
On 28 November 2012 22:25, Casimiro de Almeida Barreto
<[hidden email]> wrote:

> On 28-11-2012 19:18, Igor Stasenko wrote:
>> On 28 November 2012 22:07, Casimiro de Almeida Barreto
>> <[hidden email]> wrote:
>>> On 28-11-2012 19:05, Igor Stasenko wrote:
>>>> On 28 November 2012 21:55, Casimiro de Almeida Barreto
>>>> <[hidden email]> wrote:
>>>>> I'm usually running squeak using stackVM (which I compiled to suit my
>>>>> needs). But I just crashed against an old problem. Yesterday I gave
>>>>> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
>>>>> and this system is a ... about gcc -m32, I either use the cogvm that
>>>>> comes along the distribution or I select one pre-built from Elliot.
>>>>> Unecessary to say that I had all sorts of problems with NativeBoost not
>>>>> being able to call the foreign libraries...
>>>> NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
>>>> don't have NB plugin and some small changes to VM itself to support
>>>> native code in 'NB' way.
>>> In Pharo I use Jenkins integrated cogvm with NB.
>> ah.. ok. Just had to say in case if you unaware of it.
>>
>>>>> Then I decided to come back and try squeak with cogvm and I tried to
>>>>> suit it to run OpenGL but it fails. I think it's impossible that I'm the
>>>>> only poor mortal to have ever faced the problem of suiting FFI to
>>>>> properly run Cog in a x86_64 architecture. Have someone dealt with this
>>>>> problem???
>>>> All Cog VMs are 32-bit.  That means that you can link dynamically only
>>>> with 32-bit libraries.
>>>>
>>> I have all 32-bit libraries. System should work.
>> Try starting VM using ptrace to see where/what it tries to load and
>> why it failing.
>>
> I've attached the error log...

this won't provide any clues, because VM hides what exactly happens inside and
simply reports a failure.
i don't remember what is utility name.. ptrace or strace..
it dumps all system calls of running process,
so you can see what it tries to do, look for calls to dlopen() in particular


--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

Frank Shearar-3
On 28 November 2012 21:36, Igor Stasenko <[hidden email]> wrote:

> On 28 November 2012 22:25, Casimiro de Almeida Barreto
> <[hidden email]> wrote:
>> On 28-11-2012 19:18, Igor Stasenko wrote:
>>> On 28 November 2012 22:07, Casimiro de Almeida Barreto
>>> <[hidden email]> wrote:
>>>> On 28-11-2012 19:05, Igor Stasenko wrote:
>>>>> On 28 November 2012 21:55, Casimiro de Almeida Barreto
>>>>> <[hidden email]> wrote:
>>>>>> I'm usually running squeak using stackVM (which I compiled to suit my
>>>>>> needs). But I just crashed against an old problem. Yesterday I gave
>>>>>> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
>>>>>> and this system is a ... about gcc -m32, I either use the cogvm that
>>>>>> comes along the distribution or I select one pre-built from Elliot.
>>>>>> Unecessary to say that I had all sorts of problems with NativeBoost not
>>>>>> being able to call the foreign libraries...
>>>>> NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
>>>>> don't have NB plugin and some small changes to VM itself to support
>>>>> native code in 'NB' way.
>>>> In Pharo I use Jenkins integrated cogvm with NB.
>>> ah.. ok. Just had to say in case if you unaware of it.
>>>
>>>>>> Then I decided to come back and try squeak with cogvm and I tried to
>>>>>> suit it to run OpenGL but it fails. I think it's impossible that I'm the
>>>>>> only poor mortal to have ever faced the problem of suiting FFI to
>>>>>> properly run Cog in a x86_64 architecture. Have someone dealt with this
>>>>>> problem???
>>>>> All Cog VMs are 32-bit.  That means that you can link dynamically only
>>>>> with 32-bit libraries.
>>>>>
>>>> I have all 32-bit libraries. System should work.
>>> Try starting VM using ptrace to see where/what it tries to load and
>>> why it failing.
>>>
>> I've attached the error log...
>
> this won't provide any clues, because VM hides what exactly happens inside and
> simply reports a failure.
> i don't remember what is utility name.. ptrace or strace..

It'll be strace.

frank

> it dumps all system calls of running process,
> so you can see what it tries to do, look for calls to dlopen() in particular
>
>
> --
> Best regards,
> Igor Stasenko.
>

Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

CdAB63
In reply to this post by Igor Stasenko
On 28-11-2012 19:36, Igor Stasenko wrote:

> On 28 November 2012 22:25, Casimiro de Almeida Barreto
> <[hidden email]> wrote:
>> On 28-11-2012 19:18, Igor Stasenko wrote:
>>> On 28 November 2012 22:07, Casimiro de Almeida Barreto
>>> <[hidden email]> wrote:
>>>> On 28-11-2012 19:05, Igor Stasenko wrote:
>>>>> On 28 November 2012 21:55, Casimiro de Almeida Barreto
>>>>> <[hidden email]> wrote:
>>>>>> I'm usually running squeak using stackVM (which I compiled to suit my
>>>>>> needs). But I just crashed against an old problem. Yesterday I gave
>>>>>> Athens (pharo) a try. Pharo runs under CogVM and as I use Fedora x86_64
>>>>>> and this system is a ... about gcc -m32, I either use the cogvm that
>>>>>> comes along the distribution or I select one pre-built from Elliot.
>>>>>> Unecessary to say that I had all sorts of problems with NativeBoost not
>>>>>> being able to call the foreign libraries...
>>>>> NativeBoost won't work with VMs prebuilt from Eliot. Simply because those VMs
>>>>> don't have NB plugin and some small changes to VM itself to support
>>>>> native code in 'NB' way.
>>>> In Pharo I use Jenkins integrated cogvm with NB.
>>> ah.. ok. Just had to say in case if you unaware of it.
>>>
>>>>>> Then I decided to come back and try squeak with cogvm and I tried to
>>>>>> suit it to run OpenGL but it fails. I think it's impossible that I'm the
>>>>>> only poor mortal to have ever faced the problem of suiting FFI to
>>>>>> properly run Cog in a x86_64 architecture. Have someone dealt with this
>>>>>> problem???
>>>>> All Cog VMs are 32-bit.  That means that you can link dynamically only
>>>>> with 32-bit libraries.
>>>>>
>>>> I have all 32-bit libraries. System should work.
>>> Try starting VM using ptrace to see where/what it tries to load and
>>> why it failing.
>>>
>> I've attached the error log...
> this won't provide any clues, because VM hides what exactly happens inside and
> simply reports a failure.
> i don't remember what is utility name.. ptrace or strace..
> it dumps all system calls of running process,
> so you can see what it tries to do, look for calls to dlopen() in particular
>
>
Ok, I ltraced  & guess what: Fedora sometimes just does not have the
/usr/lib/libXX.so but only /usr/lib/libXX.so.1 (or whathever). Fixed,
got things running.

Thanks !!!




signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

Bert Freudenberg
On 2012-11-29, at 17:24, Casimiro de Almeida Barreto <[hidden email]> wrote:

> Ok, I ltraced  & guess what: Fedora sometimes just does not have the
> /usr/lib/libXX.so but only /usr/lib/libXX.so.1 (or whathever). Fixed,
> got things running.


Your code should be looking for /usr/lib/libXX.so.1 not /usr/lib/libXX.so on Linux. Adding the symlink is *not* the right way to work around that.

This is how the library versioning system was designed. Just do an "ldd" an any executable and you will see they all link to the versioned file names.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

CdAB63
On 29-11-2012 16:20, Bert Freudenberg wrote:
> On 2012-11-29, at 17:24, Casimiro de Almeida Barreto <[hidden email]> wrote:
>
>> Ok, I ltraced  & guess what: Fedora sometimes just does not have the
>> /usr/lib/libXX.so but only /usr/lib/libXX.so.1 (or whathever). Fixed,
>> got things running.
>
> Your code should be looking for /usr/lib/libXX.so.1 not /usr/lib/libXX.so on Linux. Adding the symlink is *not* the right way to work around that.
Clearly not the right way. Every time library is updated things go
borked :-)
>
> This is how the library versioning system was designed. Just do an "ldd" an any executable and you will see they all link to the versioned file names.
It happens that apparently FFI and NativeBoost have problems with native
linux versioning system. BTW, in OpenGL there's explicit link to
libGL.so (libraryName).
>
> - Bert -
>
>
>
>





signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems with CogVM

Bert Freudenberg
On 2012-11-29, at 19:42, Casimiro de Almeida Barreto <[hidden email]> wrote:

> On 29-11-2012 16:20, Bert Freudenberg wrote:
>> On 2012-11-29, at 17:24, Casimiro de Almeida Barreto <[hidden email]> wrote:
>>
>>> Ok, I ltraced  & guess what: Fedora sometimes just does not have the
>>> /usr/lib/libXX.so but only /usr/lib/libXX.so.1 (or whathever). Fixed,
>>> got things running.
>>
>> Your code should be looking for /usr/lib/libXX.so.1 not /usr/lib/libXX.so on Linux. Adding the symlink is *not* the right way to work around that.
> Clearly not the right way. Every time library is updated things go
> borked :-)
>>
>> This is how the library versioning system was designed. Just do an "ldd" an any executable and you will see they all link to the versioned file names.
> It happens that apparently FFI and NativeBoost have problems with native
> linux versioning system. BTW, in OpenGL there's explicit link to
> libGL.so (libraryName).

Not true:

OGLUnix>>openGLLibraryName
        ^Smalltalk osVersion = 'linux'
                ifTrue: ['libGL.so.1']
                ifFalse: ['GL']



- Bert -