From: SourceForge.net <no...@so...> - 2006-10-03 17:08:02
|
Bugs item #1569548, was opened at 2006-10-02 16:46 Message generated for change (Comment added) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1569548&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerard Milmeister (gemi) Assigned to: Mark Hessling (rexx) Summary: Circular dependencies in shared libraries Initial Comment: We are reviewing oorexx for inclusion in Fedora Extras. The checking tool rpmlint reports the following warnings: W: oorexx-libs undefined-non-weak-symbol /usr/lib/librxsock.so.3.0.1 RexxDeregisterFunction W: oorexx-libs undefined-non-weak-symbol /usr/lib/librxsock.so.3.0.1 RexxVariablePool W: oorexx-libs undefined-non-weak-symbol /usr/lib/librxsock.so.3.0.1 RexxRegisterFunctionDll W: oorexx-libs undefined-non-weak-symbol /usr/lib/librexxapi.so.3.0.1 TheNilObject W: oorexx-libs undefined-non-weak-symbol /usr/lib/librexxapi.so.3.0.1 RexxTerminated etc... The explanation provided by rpmlint is: "The binary contains undefined non-weak symbols. This may indicate improper linkage; check that the binary has been linked as expected." This may happen, if there is a circular dependency between two or more shared libraries. Normally this is resolved by merging both libraries, since one can obviously not exist without the other. Here is additional information about this problem: http://www.redhat.com/archives/fedora-extras-list/2006-July/msg00569.html ---------------------------------------------------------------------- >Comment By: Rick McGuire (bigrixx) Date: 2006-10-03 13:07 Message: Logged In: YES user_id=1125291 At one point, they were only sort of "semi-circular". The callback from rexxapi to rexx used to be a dynamic loading situation. After a point, it got easier to just link them. ---------------------------------------------------------------------- Comment By: Gerard Milmeister (gemi) Date: 2006-10-03 12:31 Message: Logged In: YES user_id=29522 I already suspected that there have been historical reasons. Having two shared libraries which depend on each other makes no sense, since the one always causes the other to be loaded. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2006-10-02 18:41 Message: Logged In: YES user_id=1125291 In practice, anybody runnng a Rexx program is also going to need the rxapi library loaded too. The split is based on historical reasons dating back to OS/2 1.2. The OS/2 operatng system imposed a requirement on the Rexx implementation that it take up as little memory as possible for users not actually using Rexx. One way to achieve that was to split the api functions used by the daemon process that managed the shared memory areas used for function registration, queues, etc. into a small dll that got loaded at OS boot. The rest of the interpreter was in the larger rexx.dll that only got loaded once a Rexx program was actually called. These reasons are no longer as valid as they once were, so the only remaining reason for keeping them separate is the way library linkage works....there are lot of extensions/apps out there that are linked to rexx.dll and rexxapi.dll. ---------------------------------------------------------------------- Comment By: David Ashley (wdashley) Date: 2006-10-02 18:25 Message: Logged In: YES user_id=931756 I think the need for two shared libraries is actually valid in our case. There is a shared code base for rxapi and the rexx executable that go in one shared library. There is also the code base for rexx itself that needs to be contained in a library so that the rexx executable and other programs can link to it. Having one shared library means that rxapi will take up a lot of memory for no purpose since it will not use a lot of the functionality provided by the library. Just me two cent worth :-) ---------------------------------------------------------------------- Comment By: Mark Hessling (rexx) Date: 2006-10-02 17:43 Message: Logged In: YES user_id=86185 Just what I've been waiting for; a valid reason for having one ooRexx shared library! I have a couple of propsals: 1) We should have a single shared library; suggest liboorexx.so 2) We provide symbolic links for librexx.so -> liboorexx.so and librexxapi.so -> liboorexx.so 3) This be done for the current ooRexx 3.x series 4) For ooRexx 4.x we ONLY have liboorexx.so 5) We also consider strongly, combining the libraries on other platforms; eg oorexx.dll on Windows. As the major player affected by these changes (all of my packages assume librexx.so and librexxapi.so), then I'll make the transition as painless as possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1569548&group_id=119701 |