#2144 load fails with undefined symbol message (suggested fix)

obsolete: 8.0p2
closed-rejected
5
2003-01-27
2003-01-10
Duncan Roe
No

Could not load a .so that used 8 other .so's. At least
one of the 8 had
an unused function in it which referred to a function
in another of the
8. This was reported as undefined.

I encountered this in 8.0p2 but it looks as if 8.4.1
will have the same
problem.

Sorry there's no test case but the following patch
fixed it for me:

--- tclLoadDl.c 2003/01/09 18:20:23 1.1
+++ tclLoadDl.c 2003/01/09 18:20:26
@@ -70,7 +70,7 @@
VOID *handle;
Tcl_DString newName;

- handle = dlopen(fileName, RTLD_NOW | RTLD_GLOBAL);
+ handle = dlopen(fileName, RTLD_LAZY |
RTLD_GLOBAL);
if (handle == NULL) {
Tcl_AppendResult(interp, "couldn't load file
\"", fileName,
"\": ", dlerror(), (char *) NULL);

I.e. don't try to resolve stuff we may never need.

A "proper" patch would have #ifdef RTLD_LAZY etc.

Platform: Linux 2.4.18, libc6 2.2.5, i486

Discussion

  • Kevin B KENNY

    Kevin B KENNY - 2003-01-27
    • status: open --> closed-rejected
     
  • Kevin B KENNY

    Kevin B KENNY - 2003-01-27

    Logged In: YES
    user_id=99768

    I've discussed this proposal with several other Tcl maintaners, and
    the general consensus is that the proposed change would not be
    an improvement.

    The problem is that RTLD_LAZY results in awkward behavior. In the
    current implemenation, a dynamic loading problem shows up as a Tcl
    error. This error is likely recoverable: in fact, there are several packages
    in tcllib that try several binary packages, and even fall back on pure Tcl
    implementations of their needed functionality. The alternative, deferring
    the problem, means that the [load] command fails silently, and then
    if the missing pieces are ever needed, the process aborts with an error
    that's much less easy to catch and recover.

    It's arguable that any load module that fails with RTLD_NOW but
    "succeeds" with RTLD_LAZY is exceedingly likely to abort on the missing
    pieces later on, and this abort is a mysterious core dump rather than
    a transparent Tcl error. While this is perhaps acceptable behavior in
    C, Tcl prides itself on not dumping core for user errors and common
    misconfigurations.

    If you can follow up to comp.lang.tcl with what you're trying to accomplish
    (ideally with specifics about how any why your load is failing), I'm sure
    that the friendly people there can help work out a solution that doesn't
    involve nasty surprises at run time.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks