Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

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

Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

EstebanLM

Hi,
I'm trying to compile UnixOSProcessPlugin as an external plugin for Cocoa Cog VM.
I created a project (in the future CMakeGenerator will doit, but for now it was hand), and I'm having some problems due to "Symbol not found" errors. The problems were because dependences of OSProcessPlugin with aio functions (fixed by Igor now), and with dependences with #printAllStacks.

Well... my doubt is: should OSProcessPlugin be an internal plugin? or there are something wrong?

I used OSProcessPlugin before (in 4.2.5) as an external plugin... so, I think it *should* be external, but I don't know :(

Cheers,
Esteban
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

Igor Stasenko

On 31 December 2010 01:22, Esteban Lorenzano <[hidden email]> wrote:
>
> Hi,
> I'm trying to compile UnixOSProcessPlugin as an external plugin for Cocoa Cog VM.
> I created a project (in the future CMakeGenerator will doit, but for now it was hand), and I'm having some problems due to "Symbol not found" errors. The problems were because dependences of OSProcessPlugin with aio functions (fixed by Igor now), and with dependences with #printAllStacks.
>
> Well... my doubt is: should OSProcessPlugin be an internal plugin? or there are something wrong?
>
> I used OSProcessPlugin before (in 4.2.5) as an external plugin... so, I think it *should* be external, but I don't know :(
>

it appears it won't work as external one, because of several
dependencies, which seen only if you link against main VM body.
And this should be fixed, because its lame :)

> Cheers,
> Esteban



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

johnmci

This one is tricky and yes it's linked as an external plugin .
The problem is that it needs to be weak linked against the globals that contain the argv/c etc...

Further to this see

sqSqueakMainApp.m
#warning what about these guyes?
/*** Variables -- globals for access from pluggable primitives ***/
int argCnt= 0;
char **argVec= 0;
char **envVec= 0;


which you need to properly hookup in

main.m
int main(int argc, char *argv[])

The warning is there because I didn't hook them up but just as soon as someone wanted to compile up the osprocess plugin.... (years later... )

Oh no doubt one should look at all the #warnings and ask John mmmm AND AND AND?

BTW to get it to link I had to do

OTHER_LDFLAGS = "-flat_namespace -undefined warning"

that will save oh a night of grief I think...


On 2010-12-30, at 4:25 PM, Igor Stasenko wrote:

>
> On 31 December 2010 01:22, Esteban Lorenzano <[hidden email]> wrote:
>>
>> Hi,
>> I'm trying to compile UnixOSProcessPlugin as an external plugin for Cocoa Cog VM.
>> I created a project (in the future CMakeGenerator will doit, but for now it was hand), and I'm having some problems due to "Symbol not found" errors. The problems were because dependences of OSProcessPlugin with aio functions (fixed by Igor now), and with dependences with #printAllStacks.
>>
>> Well... my doubt is: should OSProcessPlugin be an internal plugin? or there are something wrong?
>>
>> I used OSProcessPlugin before (in 4.2.5) as an external plugin... so, I think it *should* be external, but I don't know :(
>>
>
> it appears it won't work as external one, because of several
> dependencies, which seen only if you link against main VM body.
> And this should be fixed, because its lame :)
>
>> Cheers,
>> Esteban
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

David T. Lewis
 
Hi Esteban,

Please also check that you are using the latest OSProcessPlugin
from SqueakSource. I recently removed the deprecated aio methods
and a lot of other old stuff, and also made some changes for Pharo
compatibility. The up to date version should no longer have dependencies
on the aio functions.

I normally expect OSPP to be built as an external plugin on Unix
and Linux, but I do not have a Mac to test so you should follow
John's advice for this.

Let me know if the printAllStacks reference is a problem. It is
used in #primitivePrintAllStacksOnSignal but I doubt that anyone
actually uses that feature, so we can just get rid of it if it
causes problems on Mac.

The aio functions from OSProcessPlugin have all been moved to
AioPlugin (www.squeaksource.com/AioPlugin). I think that this
plugin will work on Mac, although you may need to build it
internal to make it work.

Similarly, the X11 functions from OSProcessPlugin were all moved
to XDisplayControlPlugin (www.squeaksource.com/XDCP). I do not
know if this is useful on Mac or not (probably not).

In any case, it should be possible to compile OSPP without any
X11 or aio function references now.

Dave

On Thu, Dec 30, 2010 at 05:47:52PM -0800, John M McIntosh wrote:

>
> This one is tricky and yes it's linked as an external plugin .
> The problem is that it needs to be weak linked against the globals that contain the argv/c etc...
>
> Further to this see
>
> sqSqueakMainApp.m
> #warning what about these guyes?
> /*** Variables -- globals for access from pluggable primitives ***/
> int argCnt= 0;
> char **argVec= 0;
> char **envVec= 0;
>
>
> which you need to properly hookup in
>
> main.m
> int main(int argc, char *argv[])
>
> The warning is there because I didn't hook them up but just as soon as someone wanted to compile up the osprocess plugin.... (years later... )
>
> Oh no doubt one should look at all the #warnings and ask John mmmm AND AND AND?
>
> BTW to get it to link I had to do
>
> OTHER_LDFLAGS = "-flat_namespace -undefined warning"
>
> that will save oh a night of grief I think...
>
>
> On 2010-12-30, at 4:25 PM, Igor Stasenko wrote:
>
> >
> > On 31 December 2010 01:22, Esteban Lorenzano <[hidden email]> wrote:
> >>
> >> Hi,
> >> I'm trying to compile UnixOSProcessPlugin as an external plugin for Cocoa Cog VM.
> >> I created a project (in the future CMakeGenerator will doit, but for now it was hand), and I'm having some problems due to "Symbol not found" errors. The problems were because dependences of OSProcessPlugin with aio functions (fixed by Igor now), and with dependences with #printAllStacks.
> >>
> >> Well... my doubt is: should OSProcessPlugin be an internal plugin? or there are something wrong?
> >>
> >> I used OSProcessPlugin before (in 4.2.5) as an external plugin... so, I think it *should* be external, but I don't know :(
> >>
> >
> > it appears it won't work as external one, because of several
> > dependencies, which seen only if you link against main VM body.
> > And this should be fixed, because its lame :)
> >
> >> Cheers,
> >> Esteban
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

EstebanLM

Hi Dave,
Yes I'm using the latest code on squeaksource. I tried removing printAllStack, and now I have "Symbol not found _primitiveFail"... and I think this is the limit (I also tried configuration suggested by John, but is the same)
Why this works in unix? are you exporting all symbols (something like -fvisibility=default)?

Cheers,
Esteban

El 31/12/2010, a las 3:25a.m., David T. Lewis escribió:

>
> Hi Esteban,
>
> Please also check that you are using the latest OSProcessPlugin
> from SqueakSource. I recently removed the deprecated aio methods
> and a lot of other old stuff, and also made some changes for Pharo
> compatibility. The up to date version should no longer have dependencies
> on the aio functions.
>
> I normally expect OSPP to be built as an external plugin on Unix
> and Linux, but I do not have a Mac to test so you should follow
> John's advice for this.
>
> Let me know if the printAllStacks reference is a problem. It is
> used in #primitivePrintAllStacksOnSignal but I doubt that anyone
> actually uses that feature, so we can just get rid of it if it
> causes problems on Mac.
>
> The aio functions from OSProcessPlugin have all been moved to
> AioPlugin (www.squeaksource.com/AioPlugin). I think that this
> plugin will work on Mac, although you may need to build it
> internal to make it work.
>
> Similarly, the X11 functions from OSProcessPlugin were all moved
> to XDisplayControlPlugin (www.squeaksource.com/XDCP). I do not
> know if this is useful on Mac or not (probably not).
>
> In any case, it should be possible to compile OSPP without any
> X11 or aio function references now.
>
> Dave
>
> On Thu, Dec 30, 2010 at 05:47:52PM -0800, John M McIntosh wrote:
>>
>> This one is tricky and yes it's linked as an external plugin .
>> The problem is that it needs to be weak linked against the globals that contain the argv/c etc...
>>
>> Further to this see
>>
>> sqSqueakMainApp.m
>> #warning what about these guyes?
>> /*** Variables -- globals for access from pluggable primitives ***/
>> int argCnt= 0;
>> char **argVec= 0;
>> char **envVec= 0;
>>
>>
>> which you need to properly hookup in
>>
>> main.m
>> int main(int argc, char *argv[])
>>
>> The warning is there because I didn't hook them up but just as soon as someone wanted to compile up the osprocess plugin.... (years later... )
>>
>> Oh no doubt one should look at all the #warnings and ask John mmmm AND AND AND?
>>
>> BTW to get it to link I had to do
>>
>> OTHER_LDFLAGS = "-flat_namespace -undefined warning"
>>
>> that will save oh a night of grief I think...
>>
>>
>> On 2010-12-30, at 4:25 PM, Igor Stasenko wrote:
>>
>>>
>>> On 31 December 2010 01:22, Esteban Lorenzano <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>> I'm trying to compile UnixOSProcessPlugin as an external plugin for Cocoa Cog VM.
>>>> I created a project (in the future CMakeGenerator will doit, but for now it was hand), and I'm having some problems due to "Symbol not found" errors. The problems were because dependences of OSProcessPlugin with aio functions (fixed by Igor now), and with dependences with #printAllStacks.
>>>>
>>>> Well... my doubt is: should OSProcessPlugin be an internal plugin? or there are something wrong?
>>>>
>>>> I used OSProcessPlugin before (in 4.2.5) as an external plugin... so, I think it *should* be external, but I don't know :(
>>>>
>>>
>>> it appears it won't work as external one, because of several
>>> dependencies, which seen only if you link against main VM body.
>>> And this should be fixed, because its lame :)
>>>
>>>> Cheers,
>>>> Esteban
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>
>> --
>> ===========================================================================
>> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> ===========================================================================
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

David T. Lewis
 
Hi Esteban,

You have found a bug in OSProcessPlugin. One of the primitives was
sending "self primitiveFail" where it should be "interpreterProxy
primitiveFail".  I can't explain why this does not cause problems
on Linux, but it is definitely a bug in my code, and thanks for finding
it.

The fix is in SqueakSource/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.25

The printAllStacks() function is part of the interpreter, but it
is not part of the interpreterProxy interface, so that it why it
is an issue for linking. I'm afraid that I do not know anything
about developing on a Mac, so I do not know if there is a possible
workaround for this. I guess we could add it to the interpreterProxy
interface, but I don't know if this is important for anyone, so
maybe it will be best to just remove it from OSProcessPlugin.

I expect that you will have similar issues with AioPlugin. On unix
it is built as an external plugin, but it contains references to
functions in the interpreter support code so you would probably
need to build it as an internal plugin.

Dave

On Fri, Dec 31, 2010 at 09:45:30AM -0300, Esteban Lorenzano wrote:

>
> Hi Dave,
> Yes I'm using the latest code on squeaksource. I tried removing printAllStack, and now I have "Symbol not found _primitiveFail"... and I think this is the limit (I also tried configuration suggested by John, but is the same)
> Why this works in unix? are you exporting all symbols (something like -fvisibility=default)?
>
> Cheers,
> Esteban
>
> El 31/12/2010, a las 3:25a.m., David T. Lewis escribi?:
>
> >
> > Hi Esteban,
> >
> > Please also check that you are using the latest OSProcessPlugin
> > from SqueakSource. I recently removed the deprecated aio methods
> > and a lot of other old stuff, and also made some changes for Pharo
> > compatibility. The up to date version should no longer have dependencies
> > on the aio functions.
> >
> > I normally expect OSPP to be built as an external plugin on Unix
> > and Linux, but I do not have a Mac to test so you should follow
> > John's advice for this.
> >
> > Let me know if the printAllStacks reference is a problem. It is
> > used in #primitivePrintAllStacksOnSignal but I doubt that anyone
> > actually uses that feature, so we can just get rid of it if it
> > causes problems on Mac.
> >
> > The aio functions from OSProcessPlugin have all been moved to
> > AioPlugin (www.squeaksource.com/AioPlugin). I think that this
> > plugin will work on Mac, although you may need to build it
> > internal to make it work.
> >
> > Similarly, the X11 functions from OSProcessPlugin were all moved
> > to XDisplayControlPlugin (www.squeaksource.com/XDCP). I do not
> > know if this is useful on Mac or not (probably not).
> >
> > In any case, it should be possible to compile OSPP without any
> > X11 or aio function references now.
> >
> > Dave
> >
> > On Thu, Dec 30, 2010 at 05:47:52PM -0800, John M McIntosh wrote:
> >>
> >> This one is tricky and yes it's linked as an external plugin .
> >> The problem is that it needs to be weak linked against the globals that contain the argv/c etc...
> >>
> >> Further to this see
> >>
> >> sqSqueakMainApp.m
> >> #warning what about these guyes?
> >> /*** Variables -- globals for access from pluggable primitives ***/
> >> int argCnt= 0;
> >> char **argVec= 0;
> >> char **envVec= 0;
> >>
> >>
> >> which you need to properly hookup in
> >>
> >> main.m
> >> int main(int argc, char *argv[])
> >>
> >> The warning is there because I didn't hook them up but just as soon as someone wanted to compile up the osprocess plugin.... (years later... )
> >>
> >> Oh no doubt one should look at all the #warnings and ask John mmmm AND AND AND?
> >>
> >> BTW to get it to link I had to do
> >>
> >> OTHER_LDFLAGS = "-flat_namespace -undefined warning"
> >>
> >> that will save oh a night of grief I think...
> >>
> >>
> >> On 2010-12-30, at 4:25 PM, Igor Stasenko wrote:
> >>
> >>>
> >>> On 31 December 2010 01:22, Esteban Lorenzano <[hidden email]> wrote:
> >>>>
> >>>> Hi,
> >>>> I'm trying to compile UnixOSProcessPlugin as an external plugin for Cocoa Cog VM.
> >>>> I created a project (in the future CMakeGenerator will doit, but for now it was hand), and I'm having some problems due to "Symbol not found" errors. The problems were because dependences of OSProcessPlugin with aio functions (fixed by Igor now), and with dependences with #printAllStacks.
> >>>>
> >>>> Well... my doubt is: should OSProcessPlugin be an internal plugin? or there are something wrong?
> >>>>
> >>>> I used OSProcessPlugin before (in 4.2.5) as an external plugin... so, I think it *should* be external, but I don't know :(
> >>>>
> >>>
> >>> it appears it won't work as external one, because of several
> >>> dependencies, which seen only if you link against main VM body.
> >>> And this should be fixed, because its lame :)
> >>>
> >>>> Cheers,
> >>>> Esteban
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Igor Stasenko AKA sig.
> >>
> >> --
> >> ===========================================================================
> >> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> >> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> >> ===========================================================================
> >>
> >>
> >>
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

Igor Stasenko

On 31 December 2010 16:26, David T. Lewis <[hidden email]> wrote:

>
> Hi Esteban,
>
> You have found a bug in OSProcessPlugin. One of the primitives was
> sending "self primitiveFail" where it should be "interpreterProxy
> primitiveFail".  I can't explain why this does not cause problems
> on Linux, but it is definitely a bug in my code, and thanks for finding
> it.
>
> The fix is in SqueakSource/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.25
>
> The printAllStacks() function is part of the interpreter, but it
> is not part of the interpreterProxy interface, so that it why it
> is an issue for linking. I'm afraid that I do not know anything
> about developing on a Mac, so I do not know if there is a possible
> workaround for this. I guess we could add it to the interpreterProxy
> interface, but I don't know if this is important for anyone, so
> maybe it will be best to just remove it from OSProcessPlugin.
>
> I expect that you will have similar issues with AioPlugin. On unix
> it is built as an external plugin, but it contains references to
> functions in the interpreter support code so you would probably
> need to build it as an internal plugin.
>

I think this is an abuse of dynamic linker.
A shared library should not have undefined symbols to be magically
bound later from unknown source.

What are guarantees that vm module will always have these functions?
What if i build the vm without printAllStacks as externally visible
function (and why i should not btw)?


The primitivePrintAllStacksOnSignal as to me belongs to VM core itself..
i think it would be better to move it to Interpreter code and remove
it from OSProcess plugin, thus avoiding external dependency it
creating.


As for:

>> >> #warning what about these guyes?
>> >> /*** Variables -- globals for access from pluggable primitives ***/
>> >> int                argCnt= 0;
>> >> char       **argVec= 0;
>> >> char       **envVec= 0;

these should be 'linked' through ioLoadFunction() interface,
and exposed by osXXXExports.c

see how its done for stWindow in platforms/win32/vm/sqWin32Exports.c
and then used in
./platforms/win32/plugins/FontPlugin/sqWin32FontPlugin.c:

theSTWindow = (HWND*) interpreterProxy->ioLoadFunctionFrom("stWindow","");


--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

David T. Lewis
 
On Fri, Dec 31, 2010 at 04:56:48PM +0100, Igor Stasenko wrote:

>
> On 31 December 2010 16:26, David T. Lewis <[hidden email]> wrote:
> >
> > Hi Esteban,
> >
> > You have found a bug in OSProcessPlugin. One of the primitives was
> > sending "self primitiveFail" where it should be "interpreterProxy
> > primitiveFail". ??I can't explain why this does not cause problems
> > on Linux, but it is definitely a bug in my code, and thanks for finding
> > it.
> >
> > The fix is in SqueakSource/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.25
> >
> > The printAllStacks() function is part of the interpreter, but it
> > is not part of the interpreterProxy interface, so that it why it
> > is an issue for linking. I'm afraid that I do not know anything
> > about developing on a Mac, so I do not know if there is a possible
> > workaround for this. I guess we could add it to the interpreterProxy
> > interface, but I don't know if this is important for anyone, so
> > maybe it will be best to just remove it from OSProcessPlugin.
> >
> > I expect that you will have similar issues with AioPlugin. On unix
> > it is built as an external plugin, but it contains references to
> > functions in the interpreter support code so you would probably
> > need to build it as an internal plugin.
> >
>
> I think this is an abuse of dynamic linker.
> A shared library should not have undefined symbols to be magically
> bound later from unknown source.
>
> What are guarantees that vm module will always have these functions?
> What if i build the vm without printAllStacks as externally visible
> function (and why i should not btw)?
>

Ha! And you thought that OSPP did not have any ugly hacks in it?
Wait till you see what I did to make forkSqueak work ;) ;)

>
> The primitivePrintAllStacksOnSignal as to me belongs to VM core itself..
> i think it would be better to move it to Interpreter code and remove
> it from OSProcess plugin, thus avoiding external dependency it
> creating.
>

Possibly so, although OSProcess provides a more general facility for
hooking up any OS signal to a semaphore. You can activate the
handler from the image, and restore it back to default from the
image also. Anything that hard codes signal assignments in the VM
is a Very Bad Idea, and setting up something to do the assignments
from command line arguments would probably be messy. So if someone
needs to be able to activate printing stacks while debugging some
problem, then turn off the feature later, using OSProcess is a
good way to do it. Furthermore, if someone decides to use SIGUSR1
and SIGUSR2 for other purposes, you can just pick a different signal
number to use while you debug your problem.

Actually I think that Eliot did wire up SIGUSR1 to dump stacks in
Cog, but that's going to be a problem if someone needs SIGUSR1 for
some other purpose (e.g. some library linked in to the VM in a
plugin, where the external library relies on SIGUSR1 for some
other purpose).

Dave

>
> As for:
>
> >> >> #warning what about these guyes?
> >> >> /*** Variables -- globals for access from pluggable primitives ***/
> >> >> int ?? ?? ?? ?? ?? ?? ?? ??argCnt= 0;
> >> >> char ?? ?? ?? **argVec= 0;
> >> >> char ?? ?? ?? **envVec= 0;
>
> these should be 'linked' through ioLoadFunction() interface,
> and exposed by osXXXExports.c
>
> see how its done for stWindow in platforms/win32/vm/sqWin32Exports.c
> and then used in
> ./platforms/win32/plugins/FontPlugin/sqWin32FontPlugin.c:
>
> theSTWindow = (HWND*) interpreterProxy->ioLoadFunctionFrom("stWindow","");
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.