There most certain IS a rexximage binary created by the build process. That binary is an important stage of the build process. However, that binary is NOT part of the final install. It is no longer needed once the build is complete.
Rick On Sat, Jan 5, 2019 at 6:11 AM P.O. Jonsson <oor...@jonases.se> wrote: > OK, thanks. > > I have done that (just to be sure: I assume you mean the root of the > source downloaded using svn, I have a *build* directory outside of that) > > cd ~/workspace/ooRexx-macOS1014-build/oorexxSVN > svn patch rexximage.patch > U rexxapi/client/platform/unix/SysLocalAPIManager.cpp > > I went on to build and everything went fine to the end, no rexximage > process appeared. I will do it another 10 times or so to see if it comes > back. > > Just an information: there is not rexximage *binary* created during this > process. I checked older builds and I cannot find a binary there either. In > 4.1.2 I can find a rexximage binary in /bin though. Just thought I let you > know. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se > > > > > Am 05.01.2019 um 11:42 schrieb Rick McGuire <object.r...@gmail.com>: > > You don't apply the patch directly to rexximage.cpp. The change isn't even > to that file. From the root directory of the build, just issue > > svn patch rexximage.patch > > Which will update the file SysLocalApiManager.cpp > > then rebuild. > > Rick > > On Sat, Jan 5, 2019 at 5:35 AM P.O. Jonsson <oor...@jonases.se> wrote: > >> FYI I applied it to trunk, it seems your revision is 11650, I checked out >> the latest build 11657. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se >> >> >> >> >> Am 05.01.2019 um 11:20 schrieb P.O. Jonsson <oor...@jonases.se>: >> >> Dear Rick, >> >> Having slept on it I remembered how to apply a patch, it is to the source >> code, not the executable, right? >> >> I am still on r11657 and a svn update brought me the patch and a failed >> patch attempt. Redoing it give me the same result >> >> POs-12Core-Pro:rexximage po$ patch rexximage.cpp rexximage.patch >> (Stripping trailing CRs from patch.) >> patching file rexximage.cpp >> Hunk #1 FAILED at 90. >> 1 out of 1 hunk FAILED -- saving rejects to file rexximage.cpp.rej >> POs-12Core-Pro:rexximage po$ >> >> >> <rexximage.cpp> >> <rexximage.cpp.orig> >> <rexximage.cpp.rej> >> <rexximage.patch> >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se >> >> >> >> >> Am 04.01.2019 um 21:58 schrieb Rick McGuire <object.r...@gmail.com>: >> >> I have the germ of an idea on this. Could you try the attached patch to >> see if the problem goes away? >> >> Rick >> >> On Fri, Jan 4, 2019 at 3:41 PM Rick McGuire <object.r...@gmail.com> >> wrote: >> >>> Hmmmm, this debug information doesn't make sense for a couple of >>> reasons. First of all, if rexximage was hanging this way, then the build >>> would never complete...but it does complete, so something else strange has >>> to be going on. Secondly, rexximage is completely single threaded, so it >>> should never block on any of the semaphores that way. >>> >>> I have no theories (yet) on how this can happen, but there are some >>> things you can check on or try that might shed some light on the problem. >>> >>> 1) When the build completes, is there a running rxapi process as well as >>> the rexximage process? >>> 2) You don't need to do a full build to investigate this further. cd >>> into the build bin directory and just run the rexximage binary as a >>> command. Does that also result in a phantom process? Also, try this both >>> with a running rxapi process and without one running. This could tell us if >>> this is showing up because rxapi is getting launched. >>> >>> Rick >>> >>> >>> On Fri, Jan 4, 2019 at 12:27 PM René Jansen <rvjan...@xs4all.nl> wrote: >>> >>>> The symptom dump says; >>>> >>>> 2854 ClientMessage::send() (in librexxapi.5.0.0.dylib) + 18 >>>> [0x104b99f12] >>>> 2854 >>>> LocalAPIManager::getInstance() (in librexxapi.5.0.0.dylib) + 19 >>>> [0x104b9a093] >>>> 2854 >>>> _pthread_mutex_lock_slow (in libsystem_pthread.dylib) + 285 >>>> [0x7fffc37f6519] >>>> 2854 >>>> _pthread_mutex_lock_wait (in libsystem_pthread.dylib) + 100 >>>> [0x7fffc37f8dfa] >>>> 2854 >>>> __psynch_mutexwait (in libsystem_kernel.dylib) + 10 [0x7fffc370dc22] >>>> >>>> So it appears to hang on a semaphore wait. >>>> >>>> I have not seen this problem in a long time. It seems benign. >>>> >>>> @P.O., did it start to appear with the debug builds? >>>> >>>> René. >>>> >>>> > On 4 Jan 2019, at 13:03, Rick McGuire <object.r...@gmail.com> wrote: >>>> > >>>> > I´m not sure how rexximage processes could be present without the >>>> build hanging. The only thing I can think of is that rexximage will launch >>>> rxapi, which involves a fork operation. But that process should then >>>> immediately become the rxapi process. >>>> > >>>> > Rick >>>> > >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> Oorexx-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>> <rexximage.patch>_______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
