Can plugins add libraries to unix vm?

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

Can plugins add libraries to unix vm?

Alan Sibley
Hey folks,

We are working on a plugin using the unix VM for squeak under OSX Tiger.
I'd like to have the resulting squeak VM link in some foundation  
stuff from OSX
(CoreFoundation CoreServices...). Is there a way to trigger this using
the Makefile.in stuff (tried altering XLDFLAGS, PLIBS, LIBS with no  
success).

It would be nice to have this linkage only occur if adding in our  
plugin.

Thanks in advance,
Alan


Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Bert Freudenberg-3

Am 21.12.2005 um 12:35 schrieb Alan Sibley:

> Hey folks,
>
> We are working on a plugin using the unix VM for squeak under OSX  
> Tiger.
> I'd like to have the resulting squeak VM link in some foundation  
> stuff from OSX
> (CoreFoundation CoreServices...). Is there a way to trigger this using
> the Makefile.in stuff (tried altering XLDFLAGS, PLIBS, LIBS with no  
> success).
>
> It would be nice to have this linkage only occur if adding in our  
> plugin.

Use the source, Luke:

bert.vektor platforms/unix/vm-display-Quartz % cat Makefile.inc
XCPPFLAGS=      -I$(topdir)/platforms/Cross/plugins/
B3DAcceleratorPlugin \
                 -I$(topdir)/platforms/unix/plugins/
B3DAcceleratorPlugin \
                 -framework Cocoa -framework OpenGL

PLIBS=          -Wl,-framework -Wl,Cocoa \
                 -Wl,-framework -Wl,OpenGL


- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Alan Sibley
Hmmm... when I try that... "ar" complains mightily

ar: -Wl,-framework: No such file or directory
ar: -Wl,Cocoa:.....

when vm-display-Quartz compiles and links... it doesn't look to be  
using ar.
I'm not the "makefile jockey" to quite determine why that is :(

Thanks for you patience...

On Dec 21, 2005, at 7:26 AM, Bert Freudenberg wrote:

>
> Am 21.12.2005 um 12:35 schrieb Alan Sibley:
>
>> Hey folks,
>>
>> We are working on a plugin using the unix VM for squeak under OSX  
>> Tiger.
>> I'd like to have the resulting squeak VM link in some foundation  
>> stuff from OSX
>> (CoreFoundation CoreServices...). Is there a way to trigger this  
>> using
>> the Makefile.in stuff (tried altering XLDFLAGS, PLIBS, LIBS with  
>> no success).
>>
>> It would be nice to have this linkage only occur if adding in our  
>> plugin.
>
> Use the source, Luke:
>
> bert.vektor platforms/unix/vm-display-Quartz % cat Makefile.inc
> XCPPFLAGS=      -I$(topdir)/platforms/Cross/plugins/
> B3DAcceleratorPlugin \
>                 -I$(topdir)/platforms/unix/plugins/
> B3DAcceleratorPlugin \
>                 -framework Cocoa -framework OpenGL
>
> PLIBS=          -Wl,-framework -Wl,Cocoa \
>                 -Wl,-framework -Wl,OpenGL
>
>
> - Bert -
>


Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Bert Freudenberg-3
I am not sure why ar would be involved here ... can you post the  
commands issued by make?

This is an external module, right?

- Bert -

Am 21.12.2005 um 16:18 schrieb Alan Sibley:

> Hmmm... when I try that... "ar" complains mightily
>
> ar: -Wl,-framework: No such file or directory
> ar: -Wl,Cocoa:.....
>
> when vm-display-Quartz compiles and links... it doesn't look to be  
> using ar.
> I'm not the "makefile jockey" to quite determine why that is :(
>
> Thanks for you patience...
>
> On Dec 21, 2005, at 7:26 AM, Bert Freudenberg wrote:
>
>>
>> Am 21.12.2005 um 12:35 schrieb Alan Sibley:
>>
>>> Hey folks,
>>>
>>> We are working on a plugin using the unix VM for squeak under OSX  
>>> Tiger.
>>> I'd like to have the resulting squeak VM link in some foundation  
>>> stuff from OSX
>>> (CoreFoundation CoreServices...). Is there a way to trigger this  
>>> using
>>> the Makefile.in stuff (tried altering XLDFLAGS, PLIBS, LIBS with  
>>> no success).
>>>
>>> It would be nice to have this linkage only occur if adding in our  
>>> plugin.
>>
>> Use the source, Luke:
>>
>> bert.vektor platforms/unix/vm-display-Quartz % cat Makefile.inc
>> XCPPFLAGS=      -I$(topdir)/platforms/Cross/plugins/
>> B3DAcceleratorPlugin \
>>                 -I$(topdir)/platforms/unix/plugins/
>> B3DAcceleratorPlugin \
>>                 -framework Cocoa -framework OpenGL
>>
>> PLIBS=          -Wl,-framework -Wl,Cocoa \
>>                 -Wl,-framework -Wl,OpenGL
>>
>>
>> - Bert -
>>



Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Alan Sibley
I am building an internal plugin... I can switch to external,
it would be nice for it to work either way. I will a) try external and let you know
and b) paste in the link command from the internal makefile.

Thanks
Alan


On Wednesday, December 21, 2005, at 07:46AM, Bert Freudenberg <[hidden email]> wrote:

>I am not sure why ar would be involved here ... can you post the  
>commands issued by make?
>
>This is an external module, right?
>
>- Bert -
>
>Am 21.12.2005 um 16:18 schrieb Alan Sibley:
>
>> Hmmm... when I try that... "ar" complains mightily
>>
>> ar: -Wl,-framework: No such file or directory
>> ar: -Wl,Cocoa:.....
>>
>> when vm-display-Quartz compiles and links... it doesn't look to be  
>> using ar.
>> I'm not the "makefile jockey" to quite determine why that is :(
>>
>> Thanks for you patience...
>>
>> On Dec 21, 2005, at 7:26 AM, Bert Freudenberg wrote:
>>
>>>
>>> Am 21.12.2005 um 12:35 schrieb Alan Sibley:
>>>
>>>> Hey folks,
>>>>
>>>> We are working on a plugin using the unix VM for squeak under OSX  
>>>> Tiger.
>>>> I'd like to have the resulting squeak VM link in some foundation  
>>>> stuff from OSX
>>>> (CoreFoundation CoreServices...). Is there a way to trigger this  
>>>> using
>>>> the Makefile.in stuff (tried altering XLDFLAGS, PLIBS, LIBS with  
>>>> no success).
>>>>
>>>> It would be nice to have this linkage only occur if adding in our  
>>>> plugin.
>>>
>>> Use the source, Luke:
>>>
>>> bert.vektor platforms/unix/vm-display-Quartz % cat Makefile.inc
>>> XCPPFLAGS=      -I$(topdir)/platforms/Cross/plugins/
>>> B3DAcceleratorPlugin \
>>>                 -I$(topdir)/platforms/unix/plugins/
>>> B3DAcceleratorPlugin \
>>>                 -framework Cocoa -framework OpenGL
>>>
>>> PLIBS=          -Wl,-framework -Wl,Cocoa \
>>>                 -Wl,-framework -Wl,OpenGL
>>>
>>>
>>> - Bert -
>>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Bert Freudenberg-3
External should be a lot easier to deal with. When building  
internally, the VM binary itself would have to be linked with the new  
frameworks. Not sure if the current build-infrastructure supports this.

- Bert -

Am 21.12.2005 um 18:36 schrieb Alan Sibley:

> I am building an internal plugin... I can switch to external,
> it would be nice for it to work either way. I will a) try external  
> and let you know
> and b) paste in the link command from the internal makefile.
>
> Thanks
> Alan
>
>
> On Wednesday, December 21, 2005, at 07:46AM, Bert Freudenberg  
> <[hidden email]> wrote:
>
>> I am not sure why ar would be involved here ... can you post the
>> commands issued by make?
>>
>> This is an external module, right?
>>
>> - Bert -
>>
>> Am 21.12.2005 um 16:18 schrieb Alan Sibley:
>>
>>> Hmmm... when I try that... "ar" complains mightily
>>>
>>> ar: -Wl,-framework: No such file or directory
>>> ar: -Wl,Cocoa:.....
>>>
>>> when vm-display-Quartz compiles and links... it doesn't look to be
>>> using ar.
>>> I'm not the "makefile jockey" to quite determine why that is :(
>>>
>>> Thanks for you patience...
>>>
>>> On Dec 21, 2005, at 7:26 AM, Bert Freudenberg wrote:
>>>
>>>>
>>>> Am 21.12.2005 um 12:35 schrieb Alan Sibley:
>>>>
>>>>> Hey folks,
>>>>>
>>>>> We are working on a plugin using the unix VM for squeak under OSX
>>>>> Tiger.
>>>>> I'd like to have the resulting squeak VM link in some foundation
>>>>> stuff from OSX
>>>>> (CoreFoundation CoreServices...). Is there a way to trigger this
>>>>> using
>>>>> the Makefile.in stuff (tried altering XLDFLAGS, PLIBS, LIBS with
>>>>> no success).
>>>>>
>>>>> It would be nice to have this linkage only occur if adding in our
>>>>> plugin.
>>>>
>>>> Use the source, Luke:
>>>>
>>>> bert.vektor platforms/unix/vm-display-Quartz % cat Makefile.inc
>>>> XCPPFLAGS=      -I$(topdir)/platforms/Cross/plugins/
>>>> B3DAcceleratorPlugin \
>>>>                 -I$(topdir)/platforms/unix/plugins/
>>>> B3DAcceleratorPlugin \
>>>>                 -framework Cocoa -framework OpenGL
>>>>
>>>> PLIBS=          -Wl,-framework -Wl,Cocoa \
>>>>                 -Wl,-framework -Wl,OpenGL
>>>>
>>>>
>>>> - Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

timrowledge
In reply to this post by Alan Sibley

On 21-Dec-05, at 9:36 AM, Alan Sibley wrote:

> I am building an internal plugin... I can switch to external,
> it would be nice for it to work either way. I will a) try external  
> and let you know
> and b) paste in the link command from the internal makefile.
Unless you have some particular need for the plugin to be internal  
(and the only one I can imagine is a need to distribute a single file  
executable because your users ares are inexperienced) then an  
external is much easier to live with *especially* during development.
a) you can compile it individually
b) you can load it to test
c) you can unload it
d) you can regenerate and recompile it to fix the bug you found
e) you can reload it
f) see b)

Note that barring truly nasty gotchas -that I can't recall ever  
hearing about- there is nothing to stop you developing the plugin as  
an external and then finally generating it as internal for the last  
build before shipping. All the code in the 'normal' plugins works  
either way except in a couple of cases where someone has decided to  
force a fixed dependency between the core vm and a plugin - the  
security plugin on windows comes to mind.
I don't know how unices do things like linking large libraries to  
dynamically loaded libraries (which is what external plugins are) but  
I'd be astonished if you couldn't do it. On RISC OS for example the  
socket libs and so on are linked only to the socket plugin, not to  
the core vm.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CSD: Charge Surreptitiously to DOE



Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Ian Piumarta-3
In reply to this post by Bert Freudenberg-3
On Dec 21, 2005, at 9:46 AM, Bert Freudenberg wrote:

> External should be a lot easier to deal with. When building  
> internally, the VM binary itself would have to be linked with the  
> new frameworks. Not sure if the current build-infrastructure  
> supports this.

No.  (Sorry.  It's a 'to-do' item.)

Cheers,
Ian


Reply | Threaded
Open this post in threaded view
|

Re: Can plugins add libraries to unix vm?

Alan Sibley
I'm feeling less stupid now ;)
We will be external 5 minutes after I get home tonight!

I have a suggested modification for mkmf... it doesn't
autodetect .cpp files or .M (objc++)... care for my patch?


On Wednesday, December 21, 2005, at 10:49AM, Ian Piumarta <[hidden email]> wrote:

>On Dec 21, 2005, at 9:46 AM, Bert Freudenberg wrote:
>
>> External should be a lot easier to deal with. When building  
>> internally, the VM binary itself would have to be linked with the  
>> new frameworks. Not sure if the current build-infrastructure  
>> supports this.
>
>No.  (Sorry.  It's a 'to-do' item.)
>
>Cheers,
>Ian
>
>
>

Reply | Threaded
Open this post in threaded view
|

New VMMaker/svn release

timrowledge
In reply to this post by timrowledge
Almost in time for Nigelmass (my brother's dirthday is on the 25th)  
I've just completed another step in the releasing of the 64bit clean  
VM code with the latest SVN level (1282 or thereabouts) and the SM  
package VMMaker3.8b5-64 'WillYouStillNeedMe'.

Read the comments attached to the SM package details. You must do  
certain things before it will work. Certain things will probably not  
work even then. So far it builds, compiles and runs in 32 bit form on  
RISC OS and OSX.

You will need to decide upon a way to appropriately define  
'VMENDIANNESS' (0 for little, 1 for big) as part of the compile. You  
might need to pay some attention to the definition of the  
sqFilenameFromString macro.

When we can feel confident that it is ok for a beta release I can  
make an  SVN branch to tie to the package.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computer Science: solving today's problems tomorrow.



Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

Andreas.Raab
Hi Tim -

This looks actually pretty good - I was finally able to compile a
working VM again (yay!). One problem I had was with the definition and
use of the sqFilenamefromblabla macro - ioFilenamefromblabla (the only
user of that macro) is defined as taking sqInt but the macro makes happy
use of [] which makes the compiler complain that the "subscripted value
is neither array nor pointer". This should either be cast properly or
declared to take pointer arguments.

Cheers,
   - Andreas

tim Rowledge wrote:

> Almost in time for Nigelmass (my brother's dirthday is on the 25th)  
> I've just completed another step in the releasing of the 64bit clean  VM
> code with the latest SVN level (1282 or thereabouts) and the SM  package
> VMMaker3.8b5-64 'WillYouStillNeedMe'.
>
> Read the comments attached to the SM package details. You must do  
> certain things before it will work. Certain things will probably not  
> work even then. So far it builds, compiles and runs in 32 bit form on  
> RISC OS and OSX.
>
> You will need to decide upon a way to appropriately define  
> 'VMENDIANNESS' (0 for little, 1 for big) as part of the compile. You  
> might need to pay some attention to the definition of the  
> sqFilenameFromString macro.
>
> When we can feel confident that it is ok for a beta release I can  make
> an  SVN branch to tie to the package.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Computer Science: solving today's problems tomorrow.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

David T. Lewis
In reply to this post by timrowledge
On Tue, Dec 27, 2005 at 09:28:40PM -0800, tim Rowledge wrote:
> Almost in time for Nigelmass (my brother's dirthday is on the 25th)  
> I've just completed another step in the releasing of the 64bit clean  
> VM code with the latest SVN level (1282 or thereabouts) and the SM  
> package VMMaker3.8b5-64 'WillYouStillNeedMe'.
>
> Read the comments attached to the SM package details. You must do  
> certain things before it will work. Certain things will probably not  
> work even then. So far it builds, compiles and runs in 32 bit form on  
> RISC OS and OSX.

Worked fine on Intel Linux 32 bit. That's all I've tried so far.

> You will need to decide upon a way to appropriately define  
> 'VMENDIANNESS' (0 for little, 1 for big) as part of the compile. You  
> might need to pay some attention to the definition of the  
> sqFilenameFromString macro.

The VMENDIANNESS macro should not be necessary, since endianness can
be tested at runtime. Change sets attached.

Interpreter-isBigEnder-dtl.1.cs provides the runtime check.

EndianPlugin-dtl.1.cs is a plugin to verify that it works.

This has been tested only on an Intel 32 bit box, so it needs
at least a check on a Mac. To test, build the EndianPlugin, then
evaluate "EndianPlugin endianness = Smalltalk endianness", which
should evaluate to true.

Cross posted to Mantis #2404.

Dave


Interpreter-isBigEnder-dtl.1.cs.gz (864 bytes) Download Attachment
EndianPlugin-dtl.1.cs.gz (998 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

timrowledge
In reply to this post by Andreas.Raab

On 28-Dec-05, at 6:19 PM, Andreas Raab wrote:
> problem I had was with the definition and use of the  
> sqFilenamefromblabla macro - ioFilenamefromblabla (the only user of  
> that macro) is defined as taking sqInt but the macro makes happy  
> use of [] which makes the compiler complain that the "subscripted  
> value is neither array nor pointer". This should either be cast  
> properly or declared to take pointer arguments.
Yah, the macro is a bit crufty. We should probably junk it and just  
agree to have a suitable function for all platforms. I think we  
actually *do* in fact, so it would merely involve agreeing to hook it  
up neatly everywhere. The original use for the macro was swapping  
dots with slashes for RISC OS but the requirements got a bit more  
complex and I had to implement a fairly complicated function to  
canonicalise filenames. It turns out I wasn't even using the macro  
anymore, which is just as well since I had defined it with the  
arguments in the wrong order...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: HBT: Harvest Binary Tree



Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

timrowledge
In reply to this post by David T. Lewis

On 28-Dec-05, at 6:36 PM, David T. Lewis wrote:

>
> Worked fine on Intel Linux 32 bit. That's all I've tried so far.
Excellent, thanks for testing it Dave.
>
>> You will need to decide upon a way to appropriately define
>> 'VMENDIANNESS' (0 for little, 1 for big) as part of the compile. You
>> might need to pay some attention to the definition of the
>> sqFilenameFromString macro.
>
> The VMENDIANNESS macro should not be necessary, since endianness can
> be tested at runtime. Change sets attached.
Cute! It's fractionally slower at runtime in return for slightly  
simpler make/autoconf setup. Does anyone have a strong opinion either  
way?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If it was easy, the hardware people would take care of it.



Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

Andreas.Raab
In reply to this post by timrowledge
I say, let's kick the macro then and give that function a proper
prototype. The way it is right now is really not all that useful.

Cheers,
   - Andreas

tim Rowledge wrote:

>
> On 28-Dec-05, at 6:19 PM, Andreas Raab wrote:
>
>> problem I had was with the definition and use of the  
>> sqFilenamefromblabla macro - ioFilenamefromblabla (the only user of  
>> that macro) is defined as taking sqInt but the macro makes happy  use
>> of [] which makes the compiler complain that the "subscripted  value
>> is neither array nor pointer". This should either be cast  properly or
>> declared to take pointer arguments.
>
> Yah, the macro is a bit crufty. We should probably junk it and just  
> agree to have a suitable function for all platforms. I think we  
> actually *do* in fact, so it would merely involve agreeing to hook it  
> up neatly everywhere. The original use for the macro was swapping  dots
> with slashes for RISC OS but the requirements got a bit more  complex
> and I had to implement a fairly complicated function to  canonicalise
> filenames. It turns out I wasn't even using the macro  anymore, which is
> just as well since I had defined it with the  arguments in the wrong
> order...
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: HBT: Harvest Binary Tree
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

Andreas.Raab
In reply to this post by timrowledge
>> The VMENDIANNESS macro should not be necessary, since endianness can
>> be tested at runtime. Change sets attached.
>
> Cute! It's fractionally slower at runtime in return for slightly  
> simpler make/autoconf setup. Does anyone have a strong opinion either  way?

Nope. And I don't think it matters much.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

David T. Lewis
In reply to this post by timrowledge
On Wed, Dec 28, 2005 at 06:44:48PM -0800, tim Rowledge wrote:
>
> On 28-Dec-05, at 6:36 PM, David T. Lewis wrote:
> >
> > The VMENDIANNESS macro should not be necessary, since endianness can
> > be tested at runtime. Change sets attached.
> Cute! It's fractionally slower at runtime in return for slightly  
> simpler make/autoconf setup. Does anyone have a strong opinion either  
> way?

Well, it's a bit simpler in BCPL (ref. Martin Richards' bcpl source):

  bigender := (!"AAA" & 255) = 'A' // =TRUE if running on a bigender

The slang version handles 64 bit/32 bit word size, and caches the
result so it may not be much slower.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

David T. Lewis
In reply to this post by timrowledge
On Wed, Dec 28, 2005 at 06:44:48PM -0800, tim Rowledge wrote:
>
> On 28-Dec-05, at 6:36 PM, David T. Lewis wrote:
>
> >
> > Worked fine on Intel Linux 32 bit. That's all I've tried so far.
> Excellent, thanks for testing it Dave.

Interim update on building 64 bit VMs with the latest VMM/SVN:

Unfortunately I have not been able to build a working 64 VM yet.
I'm using VMMaker-tpr.39 (loaded from Squeak Map), SVN 1282, plus my
local patches (attached for reference). The OS is 32 bit Intel Linux.

I was previously able to build a 64 bit VM with VMMaker-tpr.37 and
SVN 1259, with the same local patches.

I am building the 64 bit VM with internal plugins BalloonEnginePlugin,
BitBltSimulation, FilePlugin, and SocketPlugin, and no external plugins.
The resulting VM crashes with a segfault after entering the interpreter
and opening the display. This is using a 64 bit image that does open
successfully with my earlier 64 bit VM (VMMaker-tpr.37/SVN 1259).

Also note, VMMaker versionString => '3.8b4' should be '3.8b5-64'.

More to follow when I get it figured out.

Dave

Attachments (in zip file):

platforms-win32-plugins-FilePlugin-sqWin32FilePrims.c.diff - Change Win32
    FilePlugin to use session ID from the interpreter rather than generate its
    own value (for consistency, and also so as not to break OSPP for Win32).

platforms-Cross-vm-sqMemoryAccess.h.diff - Add missing memory access macros
    (the inline functions are complete, but some of the corresponding macros
    are missing).

platforms-unix-vm-sqUnixExternalPrims.c.diff - Provide meaningful console
    error message if an external module (e.g. vm-display-X11) fails to load.
 
platforms-unix-config-config.h.in.diff - Add a definition to unix/config/config.in
    to #define SQAIO_H "sqaio.h" due to renaming aio.h to sqaio.h. Permits OSPP
    and AIO plugins to be backward compatible with older source trees. (Note
    to Tim: RiscOS uses a copy of aio.h in its platform tree, should sqaio.h
    be moved to Cross?)



DavesPlatformPatches-SVN-1282.zip (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

timrowledge

On 29-Dec-05, at 12:00 PM, David T. Lewis wrote:

> On Wed, Dec 28, 2005 at 06:44:48PM -0800, tim Rowledge wrote:
>>
>> On 28-Dec-05, at 6:36 PM, David T. Lewis wrote:
>>
>>>
>>> Worked fine on Intel Linux 32 bit. That's all I've tried so far.
>> Excellent, thanks for testing it Dave.
>
> Interim update on building 64 bit VMs with the latest VMM/SVN:
>
> Unfortunately I have not been able to build a working 64 VM yet.
> I'm using VMMaker-tpr.39 (loaded from Squeak Map), SVN 1282, plus my
> local patches (attached for reference). The OS is 32 bit Intel Linux.
>
> I was previously able to build a 64 bit VM with VMMaker-tpr.37 and
> SVN 1259, with the same local patches.

Hmm, sadly not something I can be of much help with; no linux machine  
etc.
All I can say is that *very* little changed between .37 and .39 that  
I could imagine having any such effect. Um, well diff is your  
reasonably polite acquaintance I think.

>
> I am building the 64 bit VM with internal plugins BalloonEnginePlugin,
> BitBltSimulation, FilePlugin, and SocketPlugin, and no external  
> plugins.
> The resulting VM crashes with a segfault after entering the  
> interpreter
> and opening the display. This is using a 64 bit image that does open
> successfully with my earlier 64 bit VM (VMMaker-tpr.37/SVN 1259).
>
> Also note, VMMaker versionString => '3.8b4' should be '3.8b5-64'.
D'oh.

>
> More to follow when I get it figured out.
>
> Dave
>
> Attachments (in zip file):
>
> platforms-win32-plugins-FilePlugin-sqWin32FilePrims.c.diff - Change  
> Win32
>     FilePlugin to use session ID from the interpreter rather than  
> generate its
>     own value (for consistency, and also so as not to break OSPP  
> for Win32).
>
> platforms-Cross-vm-sqMemoryAccess.h.diff - Add missing memory  
> access macros
>     (the inline functions are complete, but some of the  
> corresponding macros
>     are missing).
OK, I knew we had skipped some but hadn't had any problems as such.

>
> platforms-unix-vm-sqUnixExternalPrims.c.diff - Provide meaningful  
> console
>     error message if an external module (e.g. vm-display-X11) fails  
> to load.
>
> platforms-unix-config-config.h.in.diff - Add a definition to unix/
> config/config.in
>     to #define SQAIO_H "sqaio.h" due to renaming aio.h to sqaio.h.  
> Permits OSPP
>     and AIO plugins to be backward compatible with older source  
> trees. (Note
>     to Tim: RiscOS uses a copy of aio.h in its platform tree,  
> should sqaio.h
>     be moved to Cross?)
It does? Gosh, I had no idea. Let me see what to do about that.
>
>
> <DavesPlatformPatches-SVN-1282.zip>


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
When you earnestly believe you can compensate for a lack of skill by  
doubling your efforts, there's no end to what you can't do





Reply | Threaded
Open this post in threaded view
|

Re: New VMMaker/svn release

Andreas.Raab
tim Rowledge wrote:

>> Unfortunately I have not been able to build a working 64 VM yet.
>> I'm using VMMaker-tpr.39 (loaded from Squeak Map), SVN 1282, plus my
>> local patches (attached for reference). The OS is 32 bit Intel Linux.
>>
>> I was previously able to build a 64 bit VM with VMMaker-tpr.37 and
>> SVN 1259, with the same local patches.
>
> Hmm, sadly not something I can be of much help with; no linux machine  etc.
> All I can say is that *very* little changed between .37 and .39 that  I
> could imagine having any such effect. Um, well diff is your  reasonably
> polite acquaintance I think.

It is possible that this might be caused by changing the compiler. Ian
and I had a lot of fun figuring out which versions of gcc are broken in
subtle enough ways so that certain "optimizations" completely break the
64bit VM. I'd try using a different version of gcc (preferredly the one
that worked before) and see if that helps.

Cheers,
   - Andreas

123