Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#1260 Tk requires same build setup as Tcl

obsolete: 8.4b2
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

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
/usr/ccs/bin/ld: illegal option -- W
usage: ld
[-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


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


    • priority: 5 --> 9
    • status: open --> open-invalid
  • Logged In: YES

    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
    Jeffrey Hobbs

    Logged In: YES

    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.

  • Jeffrey Hobbs
    Jeffrey Hobbs

    • priority: 9 --> 6
  • Mo DeJong
    Mo DeJong

    Logged In: YES

    I don't see how it is possible to configure Tk with another
    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
    Jeffrey Hobbs

    • summary: Tk fails to build on Solaris 2.6 --> Tk requires same build setup as Tcl
    • priority: 6 --> 4
  • Jeffrey Hobbs
    Jeffrey Hobbs

    Logged In: YES

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

  • Mo DeJong
    Mo DeJong

    • status: open-invalid --> closed-invalid
  • Mo DeJong
    Mo DeJong

    Logged In: YES

    I added the following to tcl/unix/README

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

  • Don Porter
    Don Porter

    Logged In: YES

    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

  • Don Porter
    Don Porter

    • priority: 4 --> 3
    • status: closed-invalid --> open-remind
  • Don Porter
    Don Porter

    • priority: 3 --> 5
  • Don Porter
    Don Porter

    Logged In: YES

    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

    $ cc -V
    cc: Forte Developer 7 C 5.4 2002/03/09
    $ setenv CC cc
    $ cd tk/solaris
    $ ../unix/configure --disable-shared
    $ 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
    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

  • Logged In: YES

    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
    Don Porter

    Logged In: YES

    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?