#191 Circular dependencies in shared libraries

closed
Mark Hessling
5
2012-08-14
2006-10-02
No

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

Discussion

  • Mark Hessling
    Mark Hessling
    2006-10-02

    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.

     
  • David Ashley
    David Ashley
    2006-10-02

    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 :-)

     
  • Rick McGuire
    Rick McGuire
    2006-10-02

    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.

     
  • 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.

     
  • Rick McGuire
    Rick McGuire
    2006-10-03

    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.

     
  • Mark Hessling
    Mark Hessling
    2006-10-14

    Logged In: YES
    user_id=86185

    Does this circular referencing prevent ooRexx from being
    included in Fedora Extras?

     
  • 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.

     
  • David Ashley
    David Ashley
    2006-11-13

    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.

     


Anonymous


Cancel   Add attachments