There are some typos to fix ..
Unlink instead of online 
PATH_MAX instead of MAX_PATH
lockFd instead of lockfd

E


> On 1 Dec 2018, at 17:24, Rick McGuire <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 <mailto:Oorexx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> <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

Reply via email to