Tcl Source Code

OriginalBugID: 1896 Bug
Version: 8.1b3
SubmitDate: '1999-04-19'
LastModified: '1999-08-13'
Severity: SER
Status: Closed
Submitter: pat
ChangedBy: hobbs
RelatedBugIDs: 957 1951 2195 1409
OS: Other
OSVersion: RedHat Linux on Alpha XL 300
Machine: NA
FixedDate: '2000-10-25'
FixedInVersion: NA
ClosedDate: '1999-08-13'


Name:
Don Porter

ObservedBehavior:
I already have Tcl 8.1b2 installed under /usr/local .

    Download and build Tcl 8.1b3:
    $ cd tcl8.1b3/unix
    $ ./configure --enable-gcc --enable-shared
    $ make runtest
    ...
    gcc -pipe -rdynamic tclTestInit.o tclTest.o tclTestObj.o
    tclTestProcBodyObj.o tclThreadTest.o   tclUnixTest.o
    -L/homeitl/dgp/tcl8.1b3/unix -ltcl8.1 -ldl  -lm -lc  -Wl,-rpath,/usr/local/lib -o tcltest
    LD_LIBRARY_PATH=`pwd`:; export LD_LIBRARY_PATH;  SHLIB_PATH=`pwd`:; export SHLIB_PATH;  TCL_LIBRARY="/homeitl/dgp/tcl8.1b3/library"; export TCL_LIBRARY;  ./tcltest
    % info patch
    8.1b2

DesiredBehavior:
I want 'make runtest' and 'make test' to test the Tcl 8.1b3 library
    that I just built, *not* the Tcl 8.1b2 library installed as
    /usr/local/lib/libtcl8.1.so, which the new library will overwrite
    when it is installed.

    Because tcl8.1b3/unix/tcltest is linked with -Wl,-rpath,/usr/local/lib,
    the path /usr/local/lib is embedded in tcltest as the first place to
    look for the libtcl8.1.so shared library it needs.  The -rpath
    apparently overrides the setting of LD_LIBRARY_PATH made when calling
    tcltest which attempts to direct tcltest to use the libtcl8.1.so in
    the current directory.  So, tcltest loads /usr/local/lib/libtcl8.1.so,
    which is the 8.1b2 library.

    The upshot is that 'make test' actually tests the old, installed library
    and probably crashes, either because a new test reveals a crash in the
    old library, or because there are symbols missing in the old library
    which the new tcltest expects to find.

    The quick workaround is to advise all installers that they must run
    'make install' before running 'make test', though that seems 
    backwards.  One would rather test before installing.  In the longer
    term, this issue needs more careful thinking through.  Testing
    in the build directory always been awkward (look at all those 
    environment variable settings just trying to make it work!), and
    it's not getting better.

    Perhaps tclsh and tcltest could be linked differently?  Use -rpath
    for tclsh, but not for tcltest?



-Wl,-rpath are necessary for normal operations.  This confusion
may occur when users are dealing with minor version releases.
See the related bug reports for the counter to this argument. 
-- 08/13/1999 hobbs

Logged In: YES 
user_id=90858

I checked in the "quick and dirty" patch to fix
the problem with tcltest on 2002-01-11. After
further reflection, it did not feel so dirty.

Logged In: YES 
user_id=80530

The quick and dirty patch makes me very happy...
...on Linux.

On Solaris, the use of ./tcltest directly from
the shell still picks up the installed library
rather than the just built one.  But even on 
Solaris, the QnD patch fixes 'make test', which
is my number one concern.

File Added - 14940: tcltest-real.patch

Logged In: YES 
user_id=90858

Well, I was assuming that people would not run the
tcltest executable directly from the command line.
They can run it from the Makefile via "make test"
or "make runtest". Of course, there really is no
reason we need to worry about burning in the build
dir name into the shared lib path since the tcltest
executable is not installed.

If your concern is that too many people are used
to running ./tcltest then the attached "quick and dirty"
patch should do the trick in a more simple way.
Of course, to really do this right would require
some more serious hacking around in tcl.m4 to
define some macros instead of this -R,-Wl with
magic variable names junk.

I don't think people running ./tclsh from the
command line is a valid concern. They can just
run "make shell" from the command line. We
can't have an executable with a burned in path
that works in both the build dir and the install
dir.

Logged In: YES 
user_id=80530

It really feels like too much and too little at
the same time.

Leaving out the burned-in shared lib path in tcltest
allows the LD_LIBRARY_PATH definition in 'make test'
to control, so that 'make test' will work properly.
However, when one wants to test just one test file:

  $ ./tcltest ../tests/append.test -verbose start

and the already-installed Tcl library happens to be
in the system load path, we still have the same problem
of testing the wrong library.  The workaround I've had to
adopt is to always configure with --disable-shared when
doing my development work.  So: too little, doesn't fully
solve the problem.

On the "too much" side:
I don't think it's reasonable to try to invent a new
make pseudo-target for every activity someone might want
to perform in the build area.  It just doesn't feel like
a solution to me; rather workaround piled on workaround.
Besides, for all these pseudo-targets to be effective,
we have to change the habits of everyone.  Almost like
forcing everyone to use a new language, rather than using
the shell commands they already know.  That's doomed to
fail.

Some of the README changes are good, and need to be done
anyway.  Also, removing @TCL_LD_SEARCH_FLAGS@ from the
tcltest target will at least solve the problem with
'make test', which is probably 95% of the issue, so
I'd support that change.  The developers will still have
to be aware of the problem and use --disable-shared.

File Added - 14914: build_tclsh.patch

Logged In: YES 
user_id=90858

Here is my implementation of option 3. Basically, I just
avoid using an executable with a burned in shared lib
path. There is no reason to burn a shared library
path into tcltest, so that problem is solved. As long
as users run Tcl from the build dir via "make shell"
then everyone will be happy. What do you think?

Logged In: YES 
user_id=80530

I'm re-opening this report because this issue is still
present in Tcl 8.3.4 and is still leading to false bug
reports.  The latest:

http://sf.net/tracker/index.php?func=detail&aid=485334&group_id=10894&atid=110894

Some possible solutions:

  1) Actually use different real names for the shared
     library of each patch release of Tcl, and link the
     tcltest executable against the real name, and tclsh
     against the soname; OR

  2) Always build the tcltest executable with the
     --disable-shared configuration; OR

  3) Whatever brilliant ideas Mo has to offer.