Can plugins add libraries to unix vm?

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

Am 21.12.2005 um 12:35 schrieb Alan Sibley:

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 -

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:

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:

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:

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:

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

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

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:

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.

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:

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

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

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.

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:

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

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

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?)

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

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.
D'oh.
OK, I knew we had skipped some but hadn't had any problems as such.
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

tim Rowledge wrote:
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