adesutherland
absolute path for loading functions does not work
This works:
rxvm ts_substr ../rexx/substr ../rexx/raise ../rexx/right
This does not work:
rxvm ts_substr /Users/rvjansen/apps/crexx_release/lib/rxfns/rexx/substr /Users/rvjansen/apps/crexx_release/lib/rxfns/rexx/raise /Users/rvjansen/apps/crexx_release/lib/rxfns/rexx/right
For some reason, something like this does work:
rxvm ts_reradix ./reradix ../../apps/crexx_release/lib/rxfns/rexx/length ../../apps/crexx_release/lib/rxfns/rexx/substr ../../apps/crexx_release/lib/rxfns/rxas/pos ../../apps/crexx_release/lib/rxfns/rxas/right ../../apps/crexx_release/lib/rxfns/rexx/raise ../../apps/crexx_release/lib/rxfns/rxas/copies
Also for plugins:
$ rxvme /Users/rvjansen/apps/crexx_release/lib/plugins/rxuuid/rx_rxuuid uuid_test
ERROR reading module file /Users/rvjansen/apps/crexx_release/lib/plugins/rxuuid/rx_rxuuid
Ready; T=0/0 18:35:41 rxvme /Users/rvjansen/apps/crexx_release/lib/plugins/rxuuid/rx_rxuuid uuid_test
$ rxvme ../../../../crexx_release/lib/plugins/rxuuid/rx_rxuuid uuid_test
5a150764-03b6-4630-a80c-f3c3514d3a0e
UUID 5a150764-03b6-4630-a80c-f3c3514d3a0e
UUIDT 9463a1fc-80b5-4c6b-82cb-4ddcf13212cd
So ? Also, took me quite some time to reproduce this - again. This makes it hard to use $CREXX_HOME in a consistent way.
with a new appreciation of this 2022 problem:
[01:13:01] rvjansen ~/test/crexx/uuid_test [master *]
$ rxc -i "../../../apps/crexx_release/lib/plugins/rxuuid" uuid_test
Ready; T=0.048/0.048 01:13:03 rxc -i "../../../apps/crexx_release/lib/plugins/rxuuid" uuid_test
[01:13:06] rvjansen ~/test/crexx/uuid_test [master *]
$ rxas uuid_test
Ready; T=0.062/0.062 01:13:11 rxas uuid_test
[01:13:12] rvjansen ~/test/crexx/uuid_test [master *]
$ rxvm ../../../apps/crexx_release/lib/plugins/rxuuid/rx_rxuuid uuid_test
8bf8f173-4cfe-4c24-bc69-00aadf793da4
UUID 8bf8f173-4cfe-4c24-bc69-00aadf793da4
UUIDT f237bcc0-62c2-4b94-bcc4-13793185055f
Ready; T=0.065/0.065 01:13:17 rxvm ../../../apps/crexx_release/lib/plugins/rxuuid/rx_rxuuid uuid_test
[01:13:45] rvjansen ~/test/crexx/uuid_test [master *]
$
this also works:
[01:20:35] rvjansen ~/test/crexx/uuid_test [master *]
$ rxvm ../../../../../Users/rvjansen/apps/crexx_release/lib/plugins/rxuuid/rx_rxuuid uuid_test
e8d3361d-4a40-40c7-b712-fba236e1599f
UUID e8d3361d-4a40-40c7-b712-fba236e1599f
UUIDT 3d5f418e-49cb-4848-a23d-f521fe6e43b6
which means I would have to back off the directory depth of my source file to travel back to / ?
unfortunately not. When I trace the OS calls with sudo fs_usage -f filesys cmd rxvme ,
10:22:32.585503 access [ 2] (___F) /Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxbin 0.000011 rxvme.18705619
10:22:32.585506 access [ 2] (___F) .//Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxbin 0.000003 rxvme.18705619
10:22:32.585509 access (___F) /Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000002 rxvme.18705619
10:22:32.585523 open [ 2] (R_____________) rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000002 rxvme.18705619
10:22:32.585524 open [ 2] (R_____________) .//Users/rvjansen/apps/crexx_release/lib/plugins/odbc 0.000001 rxvme.18705619
10:22:32.585539 stat64 [ 2] //Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000001 rxvme.18705619
10:22:32.585552 stat64 [ 2] //Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000002 rxvme.18705619
10:22:32.585563 stat64 [ 2] //Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000002 rxvme.18705619
10:22:32.585572 stat64 [ 2] //Users/rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000001 rxvme.18705619
10:22:32.585574 open [ 2] (R_____________) rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000001 rxvme.18705619
10:22:32.585575 open [ 2] (R_____________) .//Users/rvjansen/apps/crexx_release/lib/plugins/odbc 0.000001 rxvme.18705619
10:22:32.585590 write F=2 B=0x56 0.000004 rxvme.18705619
10:22:32.585725 exit [ -1] 0.
We see that there is a .// prepended to the file's absolute path; the OS gives up.
(compared to a successful execution with a relative path:
0:28:24.410993 PAGE_IN_FILE A=0x0102458000 0.000011 rxvme.18738190
10:28:24.411008 access [ 2] (___F) ../../../rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxbin 0.000007 rxvme.18738190
10:28:24.411010 access [ 2] (___F) ./../../../rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxbin 0.000001 rxvme.18738190
10:28:24.411011 access (___F) ./../../rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000002 rxvme.18738190
10:28:24.411044 open F=3 (R_____________) rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000019 rxvme.18738190
10:28:24.411045 fcntl F=3 <GETPATH> 0.000001 rxvme.18738190
10:28:24.411047 close F=3 0.000002 rxvme.18738190
10:28:24.411066 stat64 ./../../rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000003 rxvme.18738190
10:28:24.411070 stat64 ./../../rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000002 rxvme.18738190
10:28:24.411077 open F=3 (R_____________) rvjansen/apps/crexx_release/lib/plugins/odbc/rx_odbc.rxplugin 0.000008 rxvme.18738190
10:28:24.411085 fcntl F=3 <GETPATH> 0.000001 rxvme.18738190
10:28:24.411093 fcntl F=3 <ADDFILESIGS_RETURN> 0.000002 rxvme.18738190
10:28:24.411100 fstat64 F=3 0.000001 rxvme.18738190
10:28:24.411107 pread F=3 B=0x1c O=0x1c00000000 0.000007 rxvme.18738190
10:28:24.411108 pread F=3 B=0x4a0 O=0x04a000000000 0.000001 rxvme.18738190
10:28:24.411108 fcntl F=3 <ADDFILESIGS_RETURN> 0.000001 rxvme.18738190
10:28:24.411116 fcntl F=3 <CHECK_LV> 0.000008 rxvme.18738190
10:28:24.411145 close F=3 0.000001 rxvme.18738190
10:28:24.411178 open F=3 (R_____________) ../Cellar/unixodbc/2.3.12/lib/libodbc.2.dylib 0.000033 rxvme.18738190
where it reaches the odbc dylib and executes the sql query)
so I fixed that in rxpa.c with:
// OSX Version
#elif __APPLE__
// Create a full file name buffer and append the directory and file name
char* full_file_name = malloc(strlen(dir) + strlen(file_name) + 2);
if (file_name[0] == '/') {
sprintf(full_file_name, "%s", file_name);
} else {
sprintf(full_file_name, "%s/%s", dir, file_name);
}
// Load the dylib
void* hDll = dlopen(full_file_name, RTLD_LAZY);
if (!hDll) {
return -1;
}
// Get the plugin initializer address and call it
initfuncs_type init = (initfuncs_type)dlsym(hDll, "_initfuncs");
if (!init) {
return -2;
}
init(ctx);
free(full_file_name);
which works and leaves the relative path load intact. See if you approve and I'll test the other platforms.
OK - Yes although interpretor/rxvmload.c ( see around line 330 in function rxldmod() ) was fixed - the load_plugin() in rxpa.c breaks it again! The point is that rxldmod() should do the searching - load_plugin() should just load it (or fail).
So do you mind, instead, to try this - get rid of
if (!dir) dir = ".";
on line 29.
And do logic like
if (!dir) {
sprintf(full_file_name, "%s", file_name);
} else {
sprintf(full_file_name, "%s/%s", dir, file_name);
}
Basically the caller to load_plugin() should have found the file.
I'll need to look at the windows version on a windows machine as I am not sure about what to do with the SetDllDirectory(".") ....
A
will have a look at that. Will also try to avoid the malloc which is not needed when we have full path already - but must take care not to do that free() then.
dir is not always passed to load_plugin it seems - I mean with content, so that default is needed for now. Not entirely sure because of build confusions. I am going to leave it at the moment; some things learned: always do a rehash on zsh after every build (rxc started to segfault on the free() thing, kept doing that after I corrected that however and rebuilt but now it seems stable); there are intermittent dependency errors with parallel builds; I also got the {executable} not found that Peter recently saw a few times. rehash and just restarting the build seems to solve all these. At the moment, it does what I want it to do.
yes, that works. Looks very clean. Closing for now and hopefully for a long time.