#5149 unix: tcl does not create non-versioned symlinks for dso

current: 8.6.0

the tcl compilation and installation only creates libtcl8.6.so, but not libtcl.so

so it impossible to link against the .so without knowing the exact version.
since the pkgconfig file does omit this entry (bug #3598282), the only way to get the right dll to link against is by either source'ing the proprietary TclConfig.sh or grepping the /lib directory for libtcl*.so


  • rofl0r

    rofl0r - 2012-12-24
    • assigned_to: nobody --> stwo
  • Jan Nijtmans

    Jan Nijtmans - 2012-12-24

    This is by design. Extensions should not link with libtcl8.6.so, only with
    libtclstub8.x.a, this way the extension becomes runnable with
    whatever (compatible) Tcl version is available. The TEA
    (Tcl Extension Architecture) system handles just that.

    There is work ongoing to make the stub library unversioned
    (tclstub.a), but that work is not complete yet. Expected
    (hopefully) in Tcl 9.0

  • Jan Nijtmans

    Jan Nijtmans - 2012-12-24
    • labels: --> 85. tclconfig
    • assigned_to: stwo --> nijtmans
    • milestone: --> current: 8.6.0
    • status: open --> pending-invalid
  • rofl0r

    rofl0r - 2012-12-24
    • status: pending-invalid --> open-invalid
  • rofl0r

    rofl0r - 2012-12-24

    note that even creating libtcl.so.8.6 would be sufficient to link against -ldl

    i wonder why tcl does things different than anybody else for no good reason

  • rofl0r

    rofl0r - 2012-12-24

    ah thanks, good to know. my irc chat plugin needs to link against libtcl, and this turned out to be crazy difficult with standard approaches.

  • Donal K. Fellows

    The problem is that different platforms have different rules; it's really irritating when one is stuck between one group of loud people insisting that certain features are removed, another group that they work in method A out of the box, and a third group that want things to use method B. The only way to accommodate such things is by putting a horrible chunk of disgusting code in the autoconf-based machinery to adapt to all of these things (note that it's not done just by platform; the requirements of distributors, sysadmins and ordinary users on the same platform in this area are wildly divergent). The adding of the correct extra symlinks in the right places for a particular linux distribution is left to the distro's packaging maintainer.

    As it happens, we don't really recommend such relinking as you refer to except within a "minor" version series (one of which has 8.6.0 as the first member) because some functions have changed API/ABI mappings between versions. (Pure API or ABI compatibility is maintained through the use of stubbed linking, but some of the things done by general dynamic linkers are not.)

    I imagine that libtcl ought to go on your platform as libtcl8.6.so.0.0 or something like that, but I've not really thought about that. (Also, not that we consider it fine for a single system to have and make available 8.4, 8.5 and 8.6 at the same time; Tcl's designed to support that sort of thing. And commercial uses of Tcl will probably bind to a specific library instance at build time rather than allowing relinking; having a known baseline beats saving disk space.)


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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks