Compiling OSProcessPlugin for Cocoa Cog VM (Mac)

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

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

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

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

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

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

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