Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Oh, I guess that's only a Windows thing then. :-( On 1/5/2019 5:08 PM, Rick McGuire wrote: On Sat, Jan 5, 2019 at 4:53 PM Gil Barmwater > wrote: Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to all of the executables? There

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Windows != Linux, so no, there has never been a REXX_HOME variable there. Rick On Sat, Jan 5, 2019 at 6:13 PM Jeremy Nicoll wrote: > On Sat, 5 Jan 2019, at 22:08, Rick McGuire wrote: > > > There has never been a REXX_HOME environment variable. > > Yes there has. It got set by the installer

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, 5 Jan 2019, at 22:08, Rick McGuire wrote: > There has never been a REXX_HOME environment variable. Yes there has. It got set by the installer (in Windows) - it's mentioned in the installer log file. -- Jeremy Nicoll - my opinions are my own.

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Not necessary IMO, for the way ooRexx is structured now the ooRexx binary directory MUST be in the PATH Otherwise a generic rexx, would never be able to use rxqueue and rxsubcom Using objects locating them by the relative position might be needed only to Guarantee consistency to the environment

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, Jan 5, 2019 at 4:53 PM Gil Barmwater wrote: > Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to > all of the executables? > There has never been a REXX_HOME environment variable. Rick > On 1/5/2019 9:17 AM, Rick McGuire wrote: > > Actually, the path we really

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

On Sat, Jan 5, 2019 at 4:54 PM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > > > On 5 Jan 2019, at 22:32, Gil Barmwater wrote: > > Actually, the path we really need is the location of librexxapi. > > > Why ? > Because ooRexx can be used by any application. so

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

> On 5 Jan 2019, at 22:32, Gil Barmwater wrote: > >> Actually, the path we really need is the location of librexxapi. Why ? ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Not being a *ix guy, wouldn't the env. var. REXX_HOME give you the path to all of the executables? On 1/5/2019 9:17 AM, Rick McGuire wrote: Actually, the path we really need is the location of librexxapi. It looks like dladdr1() might give me the information I want, The main process

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

This link proposes otool -L to find libraries at non-standard locations at runtime https://stackoverflow.com/questions/4513799/how-to-set-the-runtime-path-rpath-of-an-executable-with-gcc-under-mac-osx?rq=1

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

If you were making a lot of calls to external rexx programs, it would try to restart rxapi on every external call. If you tried to use queues at all, you would get an error message. Rick On Sat, Jan 5, 2019 at 10:18 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net>

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Having “.” In the PATH is against any good judgement A CD to the wrong directory might, will certainly open a can of worm The rxapi thing is a pretty murky issue For basic things looks like the is not really needed I moved the rxapi away from the path And a pretty complicated script run

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

Actually, the path we really need is the location of librexxapi. It looks like dladdr1() might give me the information I want, The main process executable might be an app that is just linked to the interpreter (for example bsfoorexx used from java).

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

It would be a lot nicer if there was one standard way to do this :-( Rick On Sat, Jan 5, 2019 at 7:25 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > here are three snippets that show how to do it > > APPLE > > #include > #include > #include > #include >

Re: [Oorexx-devel] A potential problem related to the rexximage problem.

here are three snippets that show how to do it APPLE #include #include #include #include #include int main() { pid_t pid; char path[1024]; int RC; char *cp; pid = getpid(); RC = proc_pidpath (pid, path, sizeof(path)); if ( RC <= 0 ) { exit(-1);

[Oorexx-devel] A potential problem related to the rexximage problem.

I found the source of the lingering rexximage processes, but it might have uncovered a potential problem with the new rxapi daemon. On unix-based systems, rxapi is launched by doing a fork() and then calling execvp() to replace the current process image with rxapi, with the rxapi process being

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

That is what I meant. I did not see it win the resulting /bin after the build was completed. Since it was present in 4.1.2 I thought I better inform. I continue to build can now briefly see a rexximage process being created and then disappearing from the list. So it seems you fixed it. Thanks!

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

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

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

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 wrote: > FYI

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

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 : > > Dear Rick, > > Having slept on it I remembered how to apply a patch, it is to the

Re: [Oorexx-devel] Lingering RexxImage process during make process on Mac

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 resultPOs-12Core-Pro:rexximage po$ patch rexximage.cpp