Menu
▾
▴
[Oorexx-bugs] [ oorexx-Bugs-1569548 ] Circular dependencies in shared libraries
|
From: SourceForge.net <no...@so...> - 2006-11-13 14:34:18
|
Bugs item #1569548, was opened at 2006-10-02 15:46 Message generated for change (Comment added) made by wdashley 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: Closed >Resolution: Postponed Priority: 5 Private: No 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: David Ashley (wdashley) Date: 2006-11-13 08:34 Message: Logged In: YES user_id=931756 This will be fixed in version 4.0. The code for this fix is already in the SVN repository. ---------------------------------------------------------------------- Comment By: Gerard Milmeister (gemi) Date: 2006-10-14 11:42 Message: Logged In: YES user_id=29522 I have imported oorexx into Fedora Extras, and binaries for i386 and ppc have been released. There is still a problem with x64_64, since this seems to require the 32-bit version of glibc to build, which is currently not possible with the Fedora build system. The circular referencing is not a blocker, but it is of course frowned upon. It is an indication of a problem that should be resolved. ---------------------------------------------------------------------- Comment By: Mark Hessling (rexx) Date: 2006-10-13 19:55 Message: Logged In: YES user_id=86185 Does this circular referencing prevent ooRexx from being included in Fedora Extras? ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2006-10-03 12: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 11: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 17: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 17: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 16: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 |