On 01.12.2018 17:33, Enrico Sorichetti via Oorexx-devel wrote: > There are some typos to fix .. > Unlink instead of online > PATH_MAX instead of MAX_PATH > lockFd instead of lockfd Thank you Erich, that made it pass!
---rony > > >> On 1 Dec 2018, at 17:24, Rick McGuire <object.r...@gmail.com >> <mailto:object.r...@gmail.com>> wrote: >> >> Thought I had caught all of those. Just committed a fix. >> >> Rick >> >> On Sat, Dec 1, 2018 at 11:06 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at >> <mailto:rony.flatsc...@wu.ac.at>> wrote: >> >> When creating the deb-package for Ubuntu-Linux installing (and >> uninstalling) it will report >> an error: >> >> Installation: >> >> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -i >> ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb >> Selecting previously unselected package oorexx. >> (Reading database ... 438687 files and directories currently >> installed.) >> Preparing to unpack ooRexx-5.0.0-11547.ubuntu1404.x86_64.deb ... >> Unpacking oorexx (5.0.0) ... >> Setting up oorexx (5.0.0) ... >> cp: cannot stat '/usr/bin/rxapid': No such file or directory >> /var/lib/dpkg/info/oorexx.postinst: 47: >> /var/lib/dpkg/info/oorexx.postinst: >> /etc/init.d/rxapid: not found dpkg: error processing package oorexx >> (--install): >> subprocess installed post-installation script returned error exit >> status 127 >> Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ... >> Processing triggers for bamfdaemon >> (0.5.3~bzr0+16.04.20180209-0ubuntu1) ... >> Rebuilding /usr/share/applications/bamf-2.index... >> Processing triggers for mime-support (3.59ubuntu1) ... >> Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ... >> Processing triggers for man-db (2.7.5-1) ... >> Errors were encountered while processing: >> oorexx >> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ >> >> >> Deinstallation: >> >> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ sudo dpkg -r oorexx >> (Reading database ... 438790 files and directories currently >> installed.) >> Removing oorexx (5.0.0) ... >> initctl: Unable to connect to Upstart: Failed to connect to socket >> /com/ubuntu/upstart: >> Connection refused >> insserv: warning: script 'binfmt-support' missing LSB tags and >> overrides >> insserv: Default-Start undefined, assuming empty start runlevel(s) >> for script `binfmt-support' >> insserv: Default-Stop undefined, assuming empty stop runlevel(s) >> for script `binfmt-support' >> Processing triggers for man-db (2.7.5-1) ... >> Processing triggers for desktop-file-utils (0.22-1ubuntu5.2) ... >> Processing triggers for bamfdaemon >> (0.5.3~bzr0+16.04.20180209-0ubuntu1) ... >> Rebuilding /usr/share/applications/bamf-2.index... >> Processing triggers for mime-support (3.59ubuntu1) ... >> Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ... >> rony@rony-linux:~/work/oorexx/rick_rxapi_sandbox$ >> >> Probably the rxapid related commands need to be removed from CMake (do >> not know how to do >> that correctly myself, hence cannot offer a patch). >> >> --- >> >> Ad creating a RPM installer on Ubuntu: unfortunately, the resulting >> package is identified by >> "file" as a DEB package, even though running: >> >> cmake -DBUILD_RPM=1 -DOS_DIST=fedora path/to/source >> make >> cpack ./ >> >> --- >> >> Another point on Linux and MacOS: library names. It seems that if >> binaries like external Rexx >> function packages got created and linked to earlier Rexx libraries, at >> least symbolic links >> need to be present to allow them to run against ooRexx 5. >> >> Currently on Linux and MacOS the libraries that get created are in the >> form: >> >> Linux: >> >> librexxapi.so -> librexxapi.so.5.0.0 >> librexxutil.so -> librexxutil.so.5.0.0 >> .... >> >> MacOS (note 'dylib' after the version number, cf. >> <https://docstore.mik.ua/orelly/unix3/mac/ch05_04.htm> >> <https://docstore.mik.ua/orelly/unix3/mac/ch05_04.htm>): >> >> librexxapi.dylib -> librexxapi.5.0.0.dylib >> librexxutil.dylib -> librexxutil.5.0.0.dylib >> ... >> >> It seems that if one needs to use external Rexx function libraries that >> got created with >> earlier versions of Rexx that there should be symbolic links like: >> >> Linux: >> >> librexxapi.so.4 -> librexx.so >> librexxapi.so.3 -> librexx.so >> librexxapi.so.2 -> librexx.so >> >> librexxutil.so.4 -> librexxutil.so >> librexxutil.so.3 -> librexxutil.so >> librexxutil.so.2 -> librexxutil.so >> ... >> >> MacOS (note 'dylib' after the version number, cf. >> <https://docstore.mik.ua/orelly/unix3/mac/ch05_04.htm> >> <https://docstore.mik.ua/orelly/unix3/mac/ch05_04.htm>): >> >> librexxapi.4.dylib -> librexx.dylib >> librexxapi.3.dylib -> librexx.dylib >> librexxapi.2.dylib -> librexx.dylib >> >> librexxutil.4.dylib -> librexxutil.dylib >> librexxutil.3.dylib -> librexxutil.dylib >> librexxutil.2.dylib -> librexxutil.dylib >> ... >> >> So the question would be: should CMake create those symbolic links on >> Linux and MacOS in >> addition? >> >> ---rony >>
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
