#1880 prepare variable like TCL_PACKAGE_PATH in tcl.

obsolete: 8.4.9
closed-works-for-me
Don Porter
5
2005-04-27
2005-03-28
No

I don't know whether this is the problem of Fedora
Core, tk, or blt.

On Fedora Core and Red Hat Enterprise and its clone
distributions, tk is made as
make TK_LIBRARY=/usr/share/tk8.4.9

As a result, pkgIndex.tcl is installed to
/usr/lib/tk8.4.9/ and other stuff installed to
/usr/share/tk8.4.9/.

And then, build BLT from source, bltwish cannot find
tk.tcl.
So I request to add a mechanism like TCL_PACKAGE_PATH
in tcl.

Discussion

  • Don Porter
    Don Porter
    2005-03-29

    • status: open --> pending
     
  • Don Porter
    Don Porter
    2005-03-29

    • labels: 318657 --> 74. Application Embedding
    • assigned_to: hobbs --> dgp
    • milestone: --> obsolete: 8.4.9
    • status: pending --> pending-works-for-me
     
  • Don Porter
    Don Porter
    2005-03-29

    Logged In: YES
    user_id=80530

    Set the variable TK_LIBRARY at
    runtime to /usr/share/tk8.4.9 and
    tk.tcl will be found.

    Then complain to RedHat about
    delivering you a broken install,
    that you're required to work around
    with environment variables set a
    runtime.

     
    • status: pending-works-for-me --> open-works-for-me
     
  • Logged In: YES
    user_id=139853

    Don, do you have a better way of handling "multilib" libraries,
    since this is really the root of this issue.

    Multilib is used on some 64bit archs (eg x86_64 in particular)
    to allow both 32bit and 64bit programs to be able to run.
    So eg on x86_64 i386 (ia32) libs are in /usr/lib whereas
    64bit libs live in /usr/lib64: for this reason pkgIndex.tcl is
    currently installed under $libdir and not $datadir in Fedora
    Core
    since it points to the binary library. If tcl/tk could provide
    better support for this situation it would be much appreciated.

     
  • Don Porter
    Don Porter
    2005-04-22

    Logged In: YES
    user_id=80530

    The location of the pkgIndex.tcl
    file and the location of the tk.tcl
    initialization script don't necessarily
    have anything to do with each other,
    so I don't really follow the last comment.

    The question is why Fedora Core
    has chosen to install tk.tcl and
    other parts of Tk's script library
    in a different place from where Tk
    expects to find it, isn't it?

    Does the "wish" program exhibit
    similar problems, or is this just
    an issue for programs like bltwish
    that embed Tk?

    hmmm.. reading the original report
    more carefully, I see it refers to
    directories named "tk8.4.9". Standard
    Tk will install the script library into
    a directory named "tk8.4" and look
    in directories also with that name.
    Is that the root of the problem?

    If so, I'd expect "wish" to be just as
    broken as "bltwish", unless it's
    received other tweaking as well.

     
  • Don Porter
    Don Porter
    2005-04-22

    Logged In: YES
    user_id=80530

    I found a tk-8.4.9-3.src.rpm file
    "on the web" and though I'm no
    RPM expert, the spec file included
    sure looks like it's set up to set
    TK_LIBRARY to <datadir>/tk8.4 .

    Is the original report in error?
    Am I looking at the wrong RPM?
    Can you point me to the source
    RPM that's at issue, please?

     
  • Don Porter
    Don Porter
    2005-04-22

    Logged In: YES
    user_id=80530

    hmmm... key phrase here might be
    "build BLT from source". Can the
    original reporter please reveal
    what version of BLT that was?
    Pointer to a tarball if possible?

     
  • Don Porter
    Don Porter
    2005-04-22

    Logged In: YES
    user_id=80530

    another detail that might help...

    when a program reports the
    "can't find a usable tk.tcl" error,
    it normally reports a list of
    directories where it looked.
    Can the original reporter report
    that information as well, please?

     
  • Logged In: YES
    user_id=139853

    > I found a tk-8.4.9-3.src.rpm file "on the web" and though
    I'm no
    > RPM expert, the spec file included sure looks like it's
    set up to set
    > TK_LIBRARY to <datadir>/tk8.4 .

    Correct. :)

    Let me try to explain the problem better from the multilib
    point-of-view.
    When I configure upstream tk on x86_64 Fedora with our
    standard paths:

    ./configure --prefix=/usr --libdir=/usr/lib64

    then libtk*, tkConfig.sh, and tk8.4/pkgIndex.tcl get
    installed correctly under /usr/lib64, however the .tcl
    library files get installed under
    /usr/lib/tk8.4 and hence are not found. This should really
    be installed
    under /usr/share/tk8.4 since they are not architecture
    dependent.
    So this is why I set TK_LIBRARY to /usr/share/tk8.4 rather than
    /usr/lib64/tk8.4, but this breaks tcl/tk packages which
    assume effectively
    that pkgIndex.tcl and *.tcl live in the same directory iirc.

     
  • Don Porter
    Don Porter
    2005-04-25

    Logged In: YES
    user_id=80530

    thanks for the followup, but several
    questions are not answered.

    Does the "wish" program work?
    If so, can you explain how it avoids
    the "can't find a usable tk.tcl" error?

     
  • Don Porter
    Don Porter
    2005-04-25

    Logged In: YES
    user_id=80530

    while we're sorting out these details,
    the original bug reporter might make
    use of a workaround.

    Rather than use the "bltwish" program
    at all, simply use the "tclsh" program,
    and let the Tk and Blt packages come
    into the program as the [package require Tk]
    and [package require Blt] commands
    are executed.

     
  • Logged In: YES
    user_id=139853

    Yes, wish works fine on x86_64. :)
    Not completely sure why, TK_LIBRARY is embedded
    in there somewhere??

    I believe Matsuura San is aware of the "modern" way of
    loading from tclsh or wish, but likes bltwish for some
    reason... :)

    (Fwiw the blt package in Fedora Extras doesn't have bltwish.)

     
  • Don Porter
    Don Porter
    2005-04-27

    Logged In: YES
    user_id=80530

    No, the compile-time value of TK_LIBRARY
    doesn't get embedded in. So, it's currently
    a bit of a mystery why Tk_Init() could find
    tk.tcl when running inside wish, but can't
    find tk.tcl when running inside bltwish.

    I'd really like to get answers for that mystery
    before I attempt to offer advice on an
    alternative strategy. Oh well...

    Tk_Init() in Tk 8.4.9 ought to look first
    in $TK_LIBRARY, if a runtime value for
    that is available. That was my first bit
    of workaround advice, that apparently
    does work.

    Then it ought to look in directories
    named "tk8.4" that are subdirectories
    of directories on the $::auto_path.
    As I understand the Fedora modifications
    to Tcl and Tk, the directory /usr/share
    gets added to $::auto_path so the
    tk.tcl file in /usr/share/tk8.4
    ought to be found, and given reports
    that the "wish" program works, it
    appears that it is being found.

    Yet, the same Tk_Init() routine
    running inside a bltwish program
    is apparently failing. I'm inclined to
    blame BLT, and to conclude that
    on this point Fedora's Tcl/Tk mods
    seem ok.

    I'd like to be able to say such things
    with more confidence though, so it
    will help if someone can report the
    version of BLT that causes the trouble
    originally reported.

    Regarding multi-lib layout advice,
    while I think what's being done
    should work, I think it would be
    slightly better to install with
    TK_LIBRARY = $libdir/tk8.4 .
    In that configuraton, the tk.tcl
    and pkgIndex.tcl files will be
    in the same directory. That
    configuration will also mean
    that two copies of Tk's script
    library get installed, one each
    for the 32-bit and 64-bit libraries.
    That tends to offend the sensibilities
    of old farts like me and like those
    who designed the filesystem layout
    standards, since it duplicates for
    each architecture things
    that aren't architecture dependent,
    but no one's hurting that bad for
    disk space anymore.

    I'm shifting this report to
    Status: Pending. It will
    automatically close in several
    days unless someone posts
    more followup information.

     
  • Don Porter
    Don Porter
    2005-04-27

    • status: open-works-for-me --> closed-works-for-me