#1260 Tk requires same build setup as Tcl

[Larry W. Virden]

Platform: SPARC Solaris 2.6.
Sun's C compiler, version WorkShop 6 update 2 C 5.3
Patch 111679-08 2002/05/09

On Aug 7, I downloaded a fresh CVS snapshot of tk from
the ActiveState ftp site.

I configured using

$PWD/configure --prefix=/usr/tcl84 --enable-symbols
--enable-shared

I then did a make and got this error:

/usr/ccs/bin/ld -G -z text -o libtk8.4g.so tk3d.o
tkArgv.o tkAtom.o tkBind.o tk
Bitmap.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o
tkConsole.o tkCursor.o tkEr
ror.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
tkGeometry.o tkGrab.o tkGrid.o
tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o
tkPlace.o tkSelect.o tkStyle
.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkUnix.o
tkUnix3d.o tkUnixButton.o tk
UnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o
tkUnixEmbed.o tkUnixEvent
.o tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o
tkUnixMenu.o tkUnixMenubu
.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o
tkUnixSend.o tkUnixWm.o tkUnixXId
.o tkStubInit.o tkStubLib.o tkButton.o tkEntry.o
tkFrame.o tkListbox.o tkMenu.o
tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o
tkScale.o tkScrollbar.o
tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
tkCanvLine.o tkCanvPoly.o tkCanv
Ps.o tkCanvText.o tkCanvUtil.o tkCanvWind.o
tkRectOval.o tkTrig.o tkImage.o tkIm
gBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o
tkTextBTree.o tkTextDisp.o t
kTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
tkTextWind.o -lsocket -lnsl
-L/usr/openwin/lib -lX11 -ldl -lm
-L/vol/tclsrcsol/tcl84/tcl/unix -ltclstub8.4g
-Wl,-R,/usr/tcl84/lib:/usr/openwin/lib
/usr/ccs/bin/ld: illegal option -- W
usage: ld
[-abc:d:e:f:h:il:mo:p:rstu:z:B:D:F:GI:L:M:N:P:Q:R:S:VY:]
file(s)
[-a] create an absolute file
[-b] do not do special PIC
relocations in a.out
[-c file] record configuration `file'
[-d y|n] operate in dynamic|static mode
[-e sym] use `sym' as entry point address
[-f name] specify library for which this
file is an auxiliary
filter

etc.

Note that the previous version of Tk that I have been
building was using -R directory rather than
-Wl,-R,directory

[Larry W. Virden]

Logged In: YES
user_id=15949

problem appears to be related to a mismatch between the
compiler used to configure and build Tcl and the compiler
being used during configure and build of Tk. These must
match or tk's configure gets confused about the options to pass.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

This should not be the case. I made sure that the updated
TEA stuff did not rely on the exact same compiler setup as
was used for Tcl, and Tk should be the same. While the
priority isn't as high, this should be corrected.

[Mo DeJong]

Logged In: YES
user_id=90858

I don't see how it is possible to configure Tk with another
compiler.
There are all sorts of #defines that could depend on the
compiler in
use. These would be stored in the Tcl's tclConfig.sh.

Also, Tcl and Tk don't make use of the updated TEA stuff
you created in the tclconfig module.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

OK, I'm willing to let Tk tie itself closer to Tcl, but we should
make this clear in the docs.

[Mo DeJong]

Logged In: YES
user_id=90858

I added the following to tcl/unix/README

Also note that you should use the same compiler when
building extensions.

[Don Porter]

Logged In: YES
user_id=80530

re-opening this at a lower priority.

Advising to use the same compiler for all extensions
as was used for Tcl is OK as a temporary workaround.

Ultimately, though, it is not a satisfactory answer, as it
prevents the possibility of obtaining binary releases of
multiple packages from multiple sources without worrying
about the compilers used. We should not force end users
to worry about these things.

As Jeff's comments suggests, I could see Tk possibly being an
exception, but a general rule of requiring matching
compilers for
all packages is just not compatible with binary releases.
Certainly all TEA support tools we create should avoid this
problem.

[Don Porter]

Logged In: YES
user_id=80530

I just ran into this issue again
on the HEAD (8.5a0), so I thought
I'd log my trouble here as a reminder
that this problem should be corrected.

On a Solaris 9 system I build Tcl
with gcc 3.2.3:

$ setenv CC gcc
$ cd tcl/solaris
$ ../unix/configure --disable-shared
$ make

This creates working tclsh and libtcl8.5.a

Then try to build Tk/wish, but using another
compiler:

$ cc -V
cc: Forte Developer 7 C 5.4 2002/03/09
$ setenv CC cc
$ cd tk/solaris
$ ../unix/configure --disable-shared
--with-tcl=../../tcl/solaris
$ make
...
cc tkAppInit.o \
-L/local/src/tk/solaris -ltk8.5 \
-L/local/src/tcl/solaris -ltcl8.5
-L/usr/openwin/lib -lX11 -ldl -lsocket -lnsl -lm
-Wl,-R,/usr/local/lib:/usr/openwin/lib -o wish
Undefined first referenced
symbol in file
__ashldi3
/local/src/tcl/solaris/libtcl8.5.a(tclExecute.o)
__ashrdi3
/local/src/tcl/solaris/libtcl8.5.a(tclExecute.o)
__floatdidf
/local/src/tcl/solaris/libtcl8.5.a(tclExecute.o)
ld: fatal: Symbol referencing errors. No output written to wish
make: *** [wish] Error 1

Note that the errors are the same as those reported in
Tcl Bug 541181, and that bug was apparently resolved.

If this problem truly cannot be solved, and forcing use of
the same compiler for both Tcl and Tk is the only answer,
then we should rig Tk's configure script to force the issue
and ignore $CC and make use of $TCL_CC from tclConfig.sh
instead.

[Donal K. Fellows]

Logged In: YES
user_id=79902

I don't think it is possible to support the use of different
compilers when --disable-shared is specified. Not without
doing something like getting each extension to describe how
it was built and then building some kind of complex
cross-grid to determine how to link things overall if you
have A built with X, B with Y and C with Z, and $env(DEITY)
knows that that is highly unlikely to scale in any
meaningful way...

With shared libraries, it is much easier to make sure that
each lib has its bizarre compiler-specific dependencies
already satisified.

[Don Porter]

Logged In: YES
user_id=80530

OK, well falling back to testing
with shared libraries, I get the
same linker error as in the original
report, so there's still work to be done.

Seems that if/when the "wish" program
goes away, this problem will go away with it?