Bug 90160 - /usr/lib/tclConfig.sh advertises wrong configuration
Summary: /usr/lib/tclConfig.sh advertises wrong configuration
Alias: None
Product: Fedora
Classification: Fedora
Component: tcltk   
(Show other bugs)
Version: 1
Hardware: All Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Bill Huang
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-03 22:32 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-27 04:19:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Source rpm for ical to be used with FC2T1 (267.38 KB, application/octet-stream)
2004-03-15 05:18 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2003-05-03 22:32:42 UTC
Description of problem:
This script claims the following in a header comment:

# This script is intended to be included by the configure scripts
# for Tcl extensions so that they don't have to figure this all
# out for themselves.

and configure scripts indeed try to use it that way.  But it was generated
in such manner that it claims that tcl8.3 libraries are in /usr/lib/
while actually they reside in /usr/share/.

There is the same problem at least with tkConfig.sh

Moreover tclX8.3 and tkX8.3 libraries are strangely split between /usr/share
and /usr/lib which is likely also to cause troubles.

Version-Release number of selected component (if applicable):

How reproducible:
Try to recompile something which is using these libraries.
'ical' from RH 7.3 could be used. :-)  It needs 'autoconf-2.13' in
a spec file instead of just 'autoconf' and after sorting somehow mess
with libraries everything compiles and works.  For a time beeing I
used links from /usr/share/ to /usr/lib/.

Comment 1 Jens Petersen 2003-07-04 03:39:03 UTC
Thank you very much for the report.  In the next build TCL_PACKAGE_PATH
should now point to "/usr/share".

Comment 2 Jens Petersen 2003-07-04 22:00:11 UTC
The above fix is in tcl-8.3.5-90.1 and should be in rawhide soon.
Could you please test if this solves the problem for you?

Comment 3 Michal Jaegermann 2003-07-21 04:21:06 UTC
It is still PITA without those links because application sources tend
to do something like that in configuration files:


where tclConfig.sh sets TCL_PREFIX=/usr, and making that into /usr/share
obviously does not help, so one ends up with the following in a configuration

checking Tcl/Tk installation
checking for tclsh... /usr/bin/tclsh
checking for tclConfig.sh... /usr/lib/tclConfig.sh
checking for tkConfig.sh... /usr/lib/tkConfig.sh
checking for installed Tcl/Tk library files... ok
checking how to run the C preprocessor... cc -E
checking for up-to-date Tcl version in tcl.h... yes
checking for up-to-date Tk version in tk.h... yes
configure: error: I could not find the *.tcl files that are supposed
to be installed in /usr/lib/tcl8.3.

In other words links in /usr/lib to /usr/share/tcl8.3 and /usr/share/tk8.3
would be convenient but otherwise current tclConfig.sh and tkConfig.sh
files look correct.

Comment 4 Jens Petersen 2003-09-18 07:58:23 UTC
Hmmm, shouldn't those packages be using $TCL_PACKAGE_PATH instead?

Comment 5 Jens Petersen 2004-02-26 08:20:03 UTC
Is this still a problem with tcl-8.4.5 in rawhide now?

Comment 6 Michal Jaegermann 2004-02-26 22:51:13 UTC
This seems to solve the issue.  At least for this minimal sample
I tried.

Comment 7 Jens Petersen 2004-02-27 04:19:36 UTC
Thanks.  Closing, please re-open if there are still problems.

Comment 8 Jens Petersen 2004-03-09 03:15:07 UTC
This still seems to affect ical for example.

Perhaps you're right and a symlink would help to ease things. :)

Comment 9 Michal Jaegermann 2004-03-09 06:21:46 UTC
Hm, I tried that on ical at it seemed to work.  I wonder what was
a difference?  A symlink likely would make life easier in general.

Comment 10 Jens Petersen 2004-03-09 08:39:05 UTC
Oh, did you build from an srpm or just the src tarball?

Comment 11 Michal Jaegermann 2004-03-09 17:38:39 UTC
I rebuild from SRPM using a somewhat hacked up RH9 installation
on the top of which I installed recent rawhide packages.  I needed
some adjustments for a spec file in configuring and flags.  Here they
are (and I had to be explicit):

./configure \
--prefix=/usr  \
--exec-prefix=/usr \
--bindir=/usr/bin  \
--sbindir=/usr/sbin  \
--sysconfdir=/etc \
--datadir=/usr/share  \
--includedir=/usr/include  \
--libdir=/usr/lib \
--libexecdir=/usr/libexec  \
--localstatedir=/var \
--sharedstatedir=/usr/com  \
--mandir=/usr/share/man \
--infodir=/usr/share/info  \
--with-tclsh=/usr/bin/tclsh \
--with-tclconfig=/usr/lib  \
--with-tkconfig=/usr/lib  \
--cache-file=/dev/null \


Other than that I had to add 8.4 to 'legal_{tcl,tk}_versions'
for obvious reasons.  Resulting binaries seemed to work fine
after the following fragment in pref.tcl got commented out:

   if {!$tk_strictMotif} {
      bind Menubutton <Any-ButtonRelease-1> {tkMenuUnpost {}}

I did not try to investigate why really this was needed and if
there are better ways to avoid an occasional SIGSEGV.  Other than
that I did not notice any problems but testing was not very extensive.
I was mostly curious if it will be possible to find libraries and
they all seemed to be there.

Comment 12 Michal Jaegermann 2004-03-15 05:18:12 UTC
Created attachment 98531 [details]
Source rpm for ical to be used with FC2T1

I rebuild this source rpm, modified from an older original, with tcl and tk
from rawhide. AFAICS it compiles, with a spate of warnings, installs and
works just fine.  I tried that on FC1T1 and also on "extended" RH9. 'prefs.tcl'

is "fixed".  If I missed something I would like to know.

Note You need to log in before you can comment on or make changes to this bug.