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

Reply via email to