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 |
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. |
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. > >> 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 >> > > |
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. |
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. > |
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. |
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. > |
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 > > got things running. Thanks !!! signature.asc (269 bytes) Download Attachment |
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 - |
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 |
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 - |
Free forum by Nabble | Edit this page |