Bug 90160

Summary: /usr/lib/tclConfig.sh advertises wrong configuration
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: tcltkAssignee: Jens Petersen <petersen>
Status: CLOSED RAWHIDE QA Contact: Bill Huang <bhuang>
Severity: medium Docs Contact:
Priority: medium    
Version: 1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-02-27 04:19:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Source rpm for ical to be used with FC2T1 none

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):
tcl-8.3.5-88

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:

TCL_SCRIPT_DIR="$TCL_PREFIX/lib/tcl$TCL_VERSION"

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

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 \
--srcdir=. 

make OPTF="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS -fpermissive"

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.