Description of problem: Logic error failure loading required base library Incorrect results froom SysFileTree (if above circumvented) Version-Release number of selected component (if applicable): oorexx.x86_64 4.1.0-9.fc21 @fedora oorexx-docs.x86_64 4.1.0-9.fc21 @fedora oorexx-libs.x86_64 4.1.0-9.fc21 @fedora To circumvent 1st problem, add: oorexx-devel.x86_64 4.1.0-9.fc21 @fedora How reproducible: 100% Steps to Reproduce: 1.Install oorexx without oorexx-devel (a user of app wouldn't expext to need latter and there is no dependency requiredment 2.Attempt to execute any REXX program 3.Fails with "Logic Error. Failure loading required base library 4.Install oorexx-devel eliminated "Logic Error" failure, but any REXX program that invokes SysFileTree function receives back incorrect results Actual results: Error message as noted when oorexx-devel absent. With oorexx-devel, SysFileTree fails to return date, time, and size values associated with files. Expected results: Successful execution of REXX program with all documented results for SysFileTree. Additional info: The Fedora repository has had packaging problems with oorexx since at least Fedora 17 in 2011 and continuing through Fedora 19 and now with Fedora 21 (See bugs 677696 and 848998). If instead of using the Fedora repository, the single-rpm package for ooRexx (now at level 4.2.0) available through oorexx.org and SourceForge is installed, these problems are not seen. That site doesn't yet have an rpm for f21, but typically there are no strong dependencies with Fedora releases and the f20 version seems to install and work on Fedora 21. The packaging of oorexx on the Fedora 21 repository (like those of f17 and f19) has multiple problems: Firstly, one would not expect the oorexx-devel package to be required unless one were planning to do modifications to the oorexx application itself, and in keeping with that convention installing the oorexx package does not require installation of the oorexx-devel package. But without the oorexx-devel package any attempt to execute any oorexx program fails 100% of the time with "Logic Error" because a mandatory application library is missing from the oorexx package and is only supplied in oorexx-devel. Secondly, if you do install the supposedly optional oorexx-devel package, you can get REXX programs to run, but there are subtle bugs present that do not occur if you instead install oorexx from the single-rpm packaging at SourceForge. One specific failure present in the Fedora repository version, which I found because it affects my programs, relates to the REXX SysFileTree functional call, which in the Fedora repository version fails to return some documented values. Based on problem reports on oorexx, this appears most likely the result of getting some modules and libraries at incompatible maintenance levels, which suggests there could easily be other subtle problems as well. It would appear whoever attempted to isolate delopement-only parts of oorexx to a separate package did not completely understand the dependencies within the application code. I have a relatively short REXX program which demonstrates the SysFileTree problem: File cksft.rex (change value of "path" below to agree with location of this file): #!/usr/bin/rexx /* REXX cksft - Check SysFileTree for proper operation. Should by default return- date time size attr filepath. */ /* Change below to path to this exec. */ path = "~/ProgApps/REXX/cksft.rex" rsltfile = "oorexxenf.txt" /* temp file for installed pkg data*/ cmd = "yum list installed|grep -e oorexx -e ooRexx >" rsltfile Address "bash" cmd Say " oorexx Environment:" Signal ON NOTREADY Do ix = 1 To 50 nextl = LINEIN(rsltfile) Say nextl End NOTREADY: Signal OFF NOTREADY Call SysFileDelete rsltfile Say "" Call SysFileTree path, "dirout", "F" Say " Result from Call SysFileTree" path', "dirout", "F"' Do dx = 1 To dirout.0 Say dirout.dx End If Words(dirout.1) = 2 Then Say "!!!oorexx bug present, date time size not returned." Else Say " All documented parameters appear to be returned." Exit --end of file cksft.rex ---- Running ./cksft.rex with oorexx-devel present: oorexx Environment: oorexx.x86_64 4.1.0-9.fc21 @fedora oorexx-devel.x86_64 4.1.0-9.fc21 @fedora oorexx-docs.x86_64 4.1.0-9.fc21 @fedora oorexx-libs.x86_64 4.1.0-9.fc21 @fedora Result from Call SysFileTree ~/ProgApps/REXX/cksft.rex, "dirout", "F" -rwxrwxr-x /home/jcewing/ProgApps/REXX/cksft.rex !!!oorexx bug present, date time size not returned. -- If oorexx-devel.x86_64 is removed (or never installed) the result is just: ./cksft.rex Logic error: Failure loading required base library Installing the latest version ooRexx.x86_64-4.2.0-9940.fedora20.rpm from links on oorexx.org gets correct results. ./cksft.rex oorexx Environment: ooRexx.x86_64 4.2.0-9940.fedora20 Result from Call SysFileTree ~/ProgApps/REXX/cksft.rex, "dirout", "F" 4/10/15 12:43p 903 -rwxrwxr-x /home/jcewing/ProgApps/REXX/cksft.rex All documented parameters appear to be returned. From past experience with oorexx.org rpms and the Fedora oorexx rpms on f17 and f19, I am fairly certain that it is not significant that the oorexx.org version was 4.2.0 rather than 4.1.0. The observed bugs have not appeared in ANY recent versions from oorexx.org. If the Fedora repository versions of oorexx cannot be properly fixed, it would be better if they were removed from the repository, forcing those interested in REXX to visit the sites where fully functional and more recent versions of oorexx can be found.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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 21 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.
The Fedora version for this bug should be changed to f22.as it persists in f22 with all updates as of 2015-11-04 exactly as described in detail in the 2015-04-10 15:47:58 posting. This bug was in f17, f18, f19, f20, f21, and now it is verified as still in the f22 oorexx packages on the Fedora repository with latest updates installed, so whatever technique being used to carry these packages to the next Fedora release is doing a perfect job of propagating the packaging error. I feel certain from the history of this bug that it will persist in any subsequent version of Fedora unless someone either fixes the apparent packaging error or removes this package from the Fedora repository (which was one suggestion). These oorexx packages were somehow incorrectly built when they were restructured from the way the app is packaged at oorexx.org (whose packages have never shown the missing library issue or the SysFileTree bug that is in the Fedora repository packages). The verification on f22: With f22 at the latest update levels, installing oorexx-4.1.0-9.fc22 from Fedora repository also pulls in oorexx-libs-4.1.0-9 . From a directory containing the previously documented (2015-04-10) cksft.rex program, attempting to execute cksft gets 100% failure with ./cksft.rex Logic error: Failure loading required base library After install oorexx-devel-4.1.0-9.fc22 from Fedora repository, REXX programs will run, but 100% of the time have an error in the results of function SysFileTree as evidenced from the rsults of the supplied cksft test program: ./cksft.rex Result from Call SysFileTree ~/ProgApps/REXX/cksft.rex, "dirout", "F" -rwxrwxr-x /home/jcewing/ProgApps/REXX/cksft.rex !!!oorexx bug present, date time size not returned. I do not have enough knowledge of Fedora packaging or program development conventions or I would attempt to fix this myself. But just from looking at the results it appears that in the Fedora packaging (1) an essential base component of oorexx was erroneously assumed to only be relevant to doing oorexx development and was put in oorexx-devel when it should have been in oorexx; and (2) one or more components of oorexx are at at an inconsistent maintenance level with either the rest of oorexx or with Fedora. Just a wild guess, but since the observed bug occurs in extracting directory info from the system, I suspect one or more oorexx libraries in the Fedora packages are out of sync with Fedora and should have been regenerated at a new Fedora release but weren't. The filesystem for which the SysFileTree bug was verified is in ext4 format on a logical volume, in case that is relevant.
I have finished tesing this problem on Fedora 23 as well. It looks like the new release of oorexx in the Fedora 23 repository (oorexx-4.2.0-1.f23, oorexx-libs-4.2.0-1.f23, oorexx-devel-4.2.0-1.f23) has finally fixed the oorexx runtime SysFileTree problem for Fedora23. At that level the test program gets: f23wslive REXX]$ ./cksft.rex Result from Call SysFileTree ~/ProgApps/REXX/cksft.rex, "dirout", "F" 11/09/15 11:35a 1033 -rwxrwxr-x /home/jcewing/ProgApps/REXX/cksft.rex All documented parameters appear to be returned. but the problem with the undocumented dependency on oorexx-devel is still there with Fedora 23 and oorexx-4.2.0-1.f23. I just noticed Fedora 22 repository now has added a unified oorexx-4.2.0-9940.fedora package (not yet in Fedora 23 repository) which seems to be a merging of oorexx, oorexx-libs, oorexx-devel. I haven't yet tested it but if this this new release fixes the SysFileTree problem for f22 as well, merging all to a single rpm would certainly be expected to fix the remaining issue with the undocumented dependency on oorexx-devel. If a similar unified single rpm becomes available for Fedora 23, that should hopefully resolve the remaining issue there as well.
OOPS. Disregard the fedora 22 remarks in last two paragraphs of previous comment. Neither issue of #1210890 is resolved on f22 (unless you go with rpms from oorexx.org). I thought I was looking at a package list from my stripped down f22 test system, but in retrospect was obviously looking at a list from my main system. The "oorexx-4.2.0-9940.fedora" unified package is not from the Fedora repository but is of course the fully functional rpm installed from oorexx.org that was mentioned as a problem circumvention near the end of the original description entry. If the oorexx-4.2.0-1.fc23 and related rpms for for oorexx 4.2.0-1 in Fedora 23 repository were retrofitted to Fedora 22, that should at least make it possible to resolve the SysFileTree bug that is in the oorexx 4.1.0-9 version on Fedora 22.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.