Tcl Source Code

I'm using the following configure line for example:

./configure  \
--prefix=/home/peter_s/sw/tcl/tcl8.3.4 \
--libdir=/home/peter_s/sw/tcl/tcl8.3.4/testlibdir \
--enable-gcc

The configure script allows the option --libdir where it actually installs the tcl libraries and it does 
it, but fails to record this path correctly in the tclConfig.sh.

# String to pass to linker to pick up the Tcl library from its
# installed directory.
TCL_LIB_SPEC='-L/home/peter_s/sw/tcl/tcl8.3.4/lib -ltcl8.3${TCL_DBGX}'

The appropriate line in the configure{.in} is:
    TCL_LIB_SPEC="-L${exec_prefix}/lib ${TCL_LIB_FLAG}"

$libdir will be defaulted to ${exec_prefix}/lib if no --libdir switch is given.
But, if it is given the script ignores it for all that settings and uses the predefined value instead.

Expected Behavior:
I think it should be like:
    TCL_LIB_SPEC="-L${libdir} ${TCL_LIB_FLAG}"

There are actually several such references in the script.


I originally recognized this behavior with TCL8.3.3, but checked that this is the same with up to 
TCL8.4a3

Just as a background:
I'm building PostgreSQL and it uses the info in tclConfig.sh to build its TCL depended parts, like 
probably other programs as well which integrate into the TCL build. 
The build fails if the library is not found at the recorded default path.

Logged In: YES 
user_id=80530

Because that approach requires every installation
of Tcl to have its own collection of installed packages
under each separate $TCL_PREFIX and $TCL_EXEC_PREFIX.
It makes more sense to have one set of installed packages
installed in the default location to be used by whatever
version of Tcl I have "active" at the time.

Basically, I want auto_path to be 

{/usr/local/lib/tcl8.3 /usr/local/lib}

As I said, the INSTALL_ROOT approach is good enough to
achieve what I want.  And lack of sync with tclConfig.sh
and the actual installed location is *exactly* what I
want in this application.

Logged In: YES 
user_id=90858

I just don't think this usage is something that we
should be bending over backwards to support. Doing
neat tricks with symlinks is neat, but I don't see
this as a valid test case. Why can't you just pass
a --prefix argument and make a symlink to the tclsh
binary?

For example:

.../configure --prefix=${HOME}/project/install/tcl
make install

cd ~/bin
ln -s ~/project/install/tcl/bin/tclsh8.4 tclsh

That works for me and it does not require hosing
around with the Makefile. The simple fact of the
matter is that you can't edit the Makefile and
expect the tclConfig.sh file to stay in sync
automatically.

Logged In: YES 
user_id=80530

Thanks for the reminder about INSTALL_ROOT.  I can 
adapt it to do what I need.

Mo, you can close this if you like.  When we make a
release, make sure there's an entry in the changes
file about this change so that others aren't surprised
if they're doing something similar and it "breaks".

Logged In: YES 
user_id=124643

Oops, by looking at it again, I realize that there would be
a little difference between the two solutions. Using
INSTALL_ROOT you would get a structure like this:
/usr/local/install/tcl8.4a4/usr/local/bin/*
/usr/local/install/tcl8.4a4/usr/local/lib/*
/usr/local/install/tcl8.4a4/usr/local/man/*
If that's not desirable you could append
 mv $my_root/usr/local/* $my_root
 rm -r $my_root/usrto your build script get the same
structure as before.

Logged In: YES 
user_id=124643

Don, I think what you want is provided via the Makefile
variable INSTALL_ROOT. It is empty by default, but can be
set to a path that gets prepended during installation. So in
the case you describe below it would look like this:

my_root=/usr/local/install/tcl8.4a4
cd unix
./configure
make
make INSTALL_ROOT=$my_root install

I always use this technique inside the RPMs I create so that
the package to be built doesn't overwrite an already
installed version.

Logged In: YES 
user_id=80530

Thanks for looking into this.

You mean TCL_LIB_SPEC, etc.  Now I see the problem.

Let me tell you what I want to do.  Maybe you have 
an alternative for me.  I want to really install Tcl
under /usr/local/install/tcl8.4a4/ but I want it to
act like it's installed in the default location
/usr/local/.

So
$ cd unix
$ ./configure
$ make

At this point the binaries have been built with the
search path for shared libraries and the script
library compiled into them as /usr/local/lib.

Then, edit the Makefile and change the values of
prefix and exec_prefix to the real install location,
/usr/local/install/tcl8.4a4.  Then

$ make install

Now, when I decide I really want to use Tcl 8.4a4, I run a
script that makes all the symlinks to make it appear to be
in the default location.  For example,

/usr/local/bin/tclsh8.4 ->
/usr/local/install/tcl8.4a4/bin/tclsh8.4

This technique lets me quickly change from one to
another to another Tcl version for testing, but
they all appear to be installed in the same place
(and can share a single set of installed packages).

With current CVS, I have the additional step of 
editing the value of libdir in addition to prefix and
exec_prefix.

Logged In: YES 
user_id=90858

Please don't include the configure file in patches.

As far as the patch goes, it will not work because
the TCL_SRC_DIR need to be a fully qualified path
in the tclConfig.sh file. There is no exec_prefix
variable in the tclConfig.sh file, so that would
work for the Makefile but would break when some
other extension pulled in tclConfig.sh.

The only "solution" I can see for this problme is
having another set of variables that are subst'ed
into the Makefile. That strikes me as really ugly.
You can't change stuff in the Makefile and expect
the tclConfig.sh to stay in sync.

The only reason this worked before is that we
were adding the "right" thing to the tclConfig.sh
file but the "wrong" thing was getting added to
the Makefile. It was a bug not a feature :)

File Added - 16767: conf.patch

Logged In: YES 
user_id=80530

This patch makes me happier.  Any reason not to apply it?

Logged In: YES 
user_id=80530

This change has broken one of my installation practices.
I can work around it, but I'd rather not.

Is there any way you can make it so that when there
is no --libdir option given to ./configure, the result
is that the literal line

libdir= ${exec_prefix}/lib

is what ends up in the Makefile?

It's very convenient to edit a Makefile and
redirect an installation by editing only one
line instead of two.

I agree with the original report that if a
--libdir option is provided to .configure, we
should honor it (foolish though it may be to
depart from the One True Install).  But I'd
really like to preserve the status quo ante
when no such option is provided.

Logged In: YES 
user_id=90858

Fixed by checking on 2002-01-11.