Bug 90160 - /usr/lib/tclConfig.sh advertises wrong configuration
/usr/lib/tclConfig.sh advertises wrong configuration
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tcltk (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Bill Huang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-03 18:32 EDT by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-26 23:19:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Michal Jaegermann 2003-05-03 18:32:42 EDT
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-03 23:39:03 EDT
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 18:00:11 EDT
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 00:21:06 EDT
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 03:58:23 EDT
Hmmm, shouldn't those packages be using $TCL_PACKAGE_PATH instead?
Comment 5 Jens Petersen 2004-02-26 03:20:03 EST
Is this still a problem with tcl-8.4.5 in rawhide now?
Comment 6 Michal Jaegermann 2004-02-26 17:51:13 EST
This seems to solve the issue.  At least for this minimal sample
I tried.
Comment 7 Jens Petersen 2004-02-26 23:19:36 EST
Thanks.  Closing, please re-open if there are still problems.
Comment 8 Jens Petersen 2004-03-08 22:15:07 EST
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 01:21:46 EST
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 03:39:05 EST
Oh, did you build from an srpm or just the src tarball?
Comment 11 Michal Jaegermann 2004-03-09 12:38:39 EST
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 00:18:12 EST
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.