+++ This bug was initially created as a clone of Bug #677696 +++ Description of problem: No oorexx programs will execute. Fails with: Logic error: Failure loading required base library Version-Release number of selected component (if applicable): oorexx-4.1.0-2.fc14.i686 oorexx-libs-4.1.0-2.fc14.i686 How reproducible: Always Steps to Reproduce: 1. Upgrade to oorexx oorexx-4.1.0-2.fc14.i686 2. Try to execute any oorexx program 3. Actual results: error message: Logic error: Failure loading required base library Expected results: oorexx program executes correctly. Additional info: uname -a Linux FedoraD.dswaner.home 2.6.35.11-83.fc14.i686 #1 SMP Mon Feb 7 07:04:18 UTC 2011 i686 i686 i386 GNU/Linux --- Additional comment from gemi on 2011-02-15 11:40:14 EST --- It seems that oorexx dynamic loads its libraries from the .so symlink to the library, but these are in the oorexx-devel package. If the devel package is installed it should work. It is probably best to move the *.so links to the libs package, instead of trying to patch the code. --- Additional comment from jcewing on 2011-08-31 21:45:20 EDT --- This problem may be a symptom of other build problems with oorexx for f15. In particular fedora problem 427029 (The procedure SysFileTree produces wrong results) has returned with oorexx-4.1.0-3.fc14.i686, oorrexx-libs-4.1.0-3.fc15.i686, after adding oorexx-devel-4.1.0-3.fc15.i686 to circumvent the load failure. this SysFileTree problem is also described by oorexx (http://sourceforge.net/tracker/?func=detail&atid=684730&aid=2857958&group_id=119701) as being most likely caused by a bad install with mis-matched library levels. The solution there has been to re-install using versions from sourcforge, but as of 2011-08-31 sourceforge doesn't have any versions higher than f14. It almost seems like not only did the symbolic links not make it into the appropriate package, but based on oorexx bug 2857958 some of the library levels used to build the packages could be suspect. --- Additional comment from jcewing on 2012-06-12 00:14:07 EDT --- This problem is still not fixed in f17 repositories, which contain oorexx-4.1.0-4-fc17 (64-bit). Sourceforge has a f17 version of 4.1-1-7814 which is a bug fix release, but it doesn't claim to address either of the above problems. De-install of all oorexx 4.1.0-4 related packages obtained from Fedora repositories and downloading and installing ooRexx-4.1.1-7814.fedora17.x86_64.rpm from sourceforge resolves both problems. Whoever repackages this application for Fedora needs to study the packaging conventions used by sourceforge and replicate it. Sourceforge just has a single package that contains all the required libraries and symbolic links. The current Fedora packaging apparently separates required elements into a separate oorexx, oorexx-devel, and oorexx-libs packages without adding a dependency for oorexx-devel package to oorexx, and at the same time manages to get some of the libraries in those packages at an incompatible maintenance level! --- Additional comment from endoflife on 2012-08-16 17:26:50 EDT --- This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Updated this bug report to Fedora 19 and hardware x86_64, as just installed 64-bit f19 on one system and identical problem encountered with f19 with oorexx-4.1.0-6.fc19 and oorexx-libs-4.1.0-6.fc19 when installed from Fedora repositories. THIS APPARENT PACKAGING PROBLEM WAS FIRST REPORTED WITH FEDORA 14 in early 2011 and continues to propagate! De-installing all the oorexx-related packages obtained from Fedora repositories and instead installing the most recent http://www.oorexx.org rpm version, ooRexx-4.1.1-7814.fedora17.x86_64.rpm, results in a functional ooRexx (past experience with oorexx.org downloads shows compatibility across several releases of Fedora, so trying f17 version on f19 seemed rational). It would be better to remove oorexx from the Fedora repositories and force all users to go to oorexx.org for the rpm than to provide non-functional ones in the Fedora repositories for years. As noted in much earlier 2011-08-31 comments, while you may be able to get the repository version to appear to work by also installing the oorexx-devel package (not marked as a package dependency, but apparently contains some required libraries missing from oorexx and oorexx-libs packages), some of the Rexx built-in functions, like SysFileTree, then produce incorrect results, which according to oorexx.org is most likely an indication of a mismatch in version levels between the libraries and other application code. So not only would it appear that the repository oorexx packages don't have all the required libraries in the required places, it would also appear that some of these libraries are at incompatible levels.
I use the classic rexx features of oorexx on Fedora fairly extensively and have done so for quite a few years. I haven't noticed any problems, so the problem appears to be isolated to certain oorexx features. If the oorexx package does get reworked, it would nice if the rxapi could be automatically added to the init sequence, instead of the user needing to start it or add it to /etc/rc.d/rc.local, after they finally discover that they need to do so in order to use certain features.
dswaner, I'm surmising you must have also installed oorexx-devel if you are getting the Fedora repository version to work at all without the fatal "Logic Error". Since one would normally expect a "devel" package to only be required if you are planning on doing coding enhancements to REXX itself, what would clue a user planning to just run existing REXX applications to expect that oorexx-devel is a hard requirement even though the oorexx package itself doesn't define it as required? You are right that the Fedora repo packages also fail to set up the rxapid initiation correctly, although the REXX code I have must not require it because my code seems to runs equally well with or without rxapid started. The ooRexx-4.1.1-7814.fedora17.x86_64.rpm from www.oorexx.org not only includes every thing needed to make oorexx functional, it also sets up the necessary stuff to get rxapid invocations in the appropriate places in /etc/init.d and the various rcn.d directories to start it at boot time. So obviously it is possible to package this product correctly. A specific example of the failure with the Fedora repo packages can be illustrated by a ~/tstsft directory containing the single file tstsft.rex: #!/usr/bin/rexx /* REXX testsft - Test SysFileTree for correct behavior */ dir = "~/testsft" /* a directory with something in it */ Call SysFileTree dir"/*.*" , "dirout", "F" /* get dir file info*/ /* show 1st file - correct result is "fdate ftime size attr fullpath" */ Say "##"dirout.1"##" Return 0 Executing this on a system with the package from oorexx.org gives the correct, as documented, directory results of: [jcewing@ins530 ~]$ ./testsft/testsft.rex ## 7/22/13 2:37p 305 -rwxrwxr-x /home/jcewing/testsft/testsft.rex## Executing this same script on a test f19 virtual machine using the oorexx, oorexx-libs, and oorexx-devel installed from the default Fedora repositories, with or without rxapid started, gives: [jcewing@f1964vb ~]$ ./testsft/testsft.rex ##-rwxrwxr-x /home/jcewing/testsft/testsft.rex## Note that the required date, time, and size fields fail to be returned by SysFileTree with the Fedora packages. This is the only bug I encountered before I switched to the oorexx.org package version, so I can't say for sure whether there are or are not other bugs present, although your experience suggests there can't be many or you should have encountered them. Something is apparently inconsistent in the way the Fedora repository packages were built or they should be producing the same results as code direct from oorexx.org.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.