Solaris is the marketing name for Sun Microsystem's SPARC and Intel Unix products.

Some tips and tricks for Tcl/Tk and extensions on Solaris.

Getting Tcl/Tk for Solaris:

Building Tcl/Tk source code on Solaris:

First, make absolutely sure you have eradicated all instances of /usr/ucb from your environment. Remove instances from your PATH, LD_LIBRARY_PATH, etc. until the following command comes up empty:

  env | grep /usr/ucb

The reason for doing this is that there are, in various combinations of Solaris, conflicts between the functions found in the /usr/ucb libraries and the /usr/lib libraries. Mixing the two is almost certain to cause malfunctioning applications on various iterations of Solaris. For instance, one conflict that LV has found is that at times, using functions compiled against the /usr/ucb libraries results in directory reading functions which think they are a different format than libraries compiled against non-ucb libraries. This manifests itself as glob's failing, or directory entries missing letters, etc.

A decent ANSI C compiler should be your next quest and you basically have two choices -- the free gcc compiler or Sun's C compiler.


Pre-built binaries for specific versions of Solaris

SunPro/Forte C:

The name has apparently evolved now. More information is available at as are trial downloads. Historically the SunPro compiler had done a better job at high optimization levels, which are mostly irrelevant for Tcl/Tk and extensions.

To work around the compilations bugs like

cg: assertion failed in file ...

add -O2 to CFLAGS (or get rid of -O in the Makefile)

Other build tools:

Be certain to have /usr/ccs/bin in your PATH, so that you can find make, ar, and other useful tools.

Note that Tcl source, as well as a number of Tcl community extensions, default to expecting the make command to be the gnu make command, and in some cases, will not build successfully without that specific make command.

The Build:

Once you have either of the above compilers installed and in your path, Tcl source and most extensions should build with:

  ./configure && make && make test && make install

If you want to use cc, consider a slight variant:

   export CC
  ./configure && make && make test && make install

Otherwise, the configure defaults to looking for gcc .

WARNING! Solaris comes with a file called /usr/ucb/cc . This is a shell that sets environment flags , etc. to put the ucb libraries into the compile environment. Be certain NOT to run that version of cc (see above).

Martin Lemburg 11.02.2003:

I just built tcl 8.3.5 on Solaris 2.8 and had following problems:

  • the configure script doesn't build in the usage of the switch HAVE_TIMEZONE_VAR
  • the configure script uses CC instead of cc (on IRIX and AIX no problem)
  • the configure script doesn't build in the usage of the libraries socket and nsl

Since building tcl 8.0.5 in 1999 on Solaris I have these problems with the configure script. Couldn't someone on the distribution team change this?

Note that I have been building Tcl on Solaris since the late 80s and I don't see the problem that Martin reports.

Also, I don't see the situation being quite as desperate with regards to removing ucb from your environment. You just need to make certain that you don't use /usr/ucb/cc as your compiler.

Also, note that Solaris 8 comes with an installation disk that contains gcc, if you can't afford Sun ONE's compiler. The remark regarding CC above is however quite important.

Another thing I have found when building some Tcl applications and extensions is that when I install Tcl/Tk into some non-standard directory, I sometimes have to edit the generated Makefile to include a -R flag for each -L flag that is used when creating .so libraries or any executable programs.

Martin Lemburg 11.02.2003:

  • We don't use ucb. We have restrictions for the usage of our compilation/linkage environment. We are even not allowed to use gcc.
  • We use /opt/SUNWspro/WS6U2/bin/CC as CC and /opt/SUNWspro/WS6U2/bin/cc as cc.
  • Compiling with CC results in an abort while trying to compile the first source file
  • Could someone suggest what should be done that the configure script recognize the usage of the timezone variable?
  • Could someone suggest what should be done that the configure script recognize the usage of libsocket and libnsl?
  • the problems I have since 1999 in building tcl on Solaris where ever the same. The workstation I built on, was updated since 1999 regulary from Solaris 2.5 to 2.8, but it is probably not configured in an optimal way.

Have you reported the errors to the bug data base at ?

Martin Lemburg 11.02.2003:

Sorry ... no - but 'd just changed it.

Martin Lemburg 11.02.2003: Me again ... we built tcl 8.3.5 with 64bit and our application uses Motif 1.1. The problem is, that for compability issues the opendir, readdir, closedir functions are redefined within tcl and that now Motif has problems with the redefined symbols. I deleted the symbol USE_DIRENT2 and the file compat/opendir.c from the makefile and recompiled. Everything seems to work, but we are a little bit afraid of causing now trouble with this changes!

Could anybody help?

I don't understand this description of the problem - but then, I don't use Motif. I'm rather surprised that Tcl is redefining standard functions.

Note that I just built tcl 8.3.5 on sparc solaris 8 using Sun's solaris c compiler version 5.3 and the test suite only fails one test. I think that something else on your system is contributing to some problems - I just don't know what.

Could you consider trying the ActiveTcl Solaris binary distribution available from ActiveState?

Martin Lemburg 17.02.2003:

The problem, why we don't use the standard distribution from ActiveState for Solaris, is, that we don't know how the static libraries are built! That's all! Just because we have to fulfill the company's policy in building binaries!

I don't know either, why tcl overloads on Solaris the opendir, closedir, readdir capabilities of the OS. On IRIX and AIX this doesn't happen! I thought this overloading exists to ensure that every OS behaves the same, right?

If I don't prevent the overloading of readdir, a MOTIF file selection box will cause a gpf. We isolated the problem in the call of readdir and looked for a possible reason. After preventing the overload of readdir & Co everything was fine.

Perhaps the configure mechanism is not able to recognize several issues on Solaris?

Like the usage of the timzone variable, the libraries libsocket.a and libnsl.a, the need of the usage of cc instead of CC?

LV I wonder if the overloading is to support VFS?

LV May 11, 2005: For some reason, Sun ships Solaris 10 with Tcl/Tk 8.3.3, TclX 8.2, Expect 5.39, and GraphViz 1.10 in the optional freely distributable software cd that mounts normally in /opt/sfw . I wonder whom could be contacted to get them to update to something a bit more up to date?

HTL 2006-08-05: Sun Solaris 10's came from My reason for not using the binaries from either SFW or ActiveState is that they are 32-bit while I need 64-bit one to run tests against 64-bit applications.

LV Thankfully, the source is available to provide such functionality. Be sure to post bug reports and patches to the appropriate web sites if you encounter problems in the 64 bit environment.

LV A question came up on the itcl mailing list. A member is using Solaris 9. She has gcc 3.3 available. She uses

$ cd ~/temp/itcl3.2.1 $ ./configure --prefix=/home/person --with-tcl=/home/person/lib/tcl8.4

as her configure statement. When she does the compile, she gets:

$ make all : stuff : cc -DVERSION=\"3.2\" -DUSE_TCL_STUBS=1 -DITCL_LIBRARY=\"/home/person/lib/itcl3.2\" -I/home/person/temp/tcl8.4.14/generic -I/home/person/temp/tcl8.4.14/unix -I"./generic" -I"./unix" -O -fPIC -c echo ./generic/itcl_cmds.c -o itcl_cmds.o cc: Warning: illegal option -fPIC

From googling, it seems as if the configure built the makefiles as if GNU programs were going to be used, but then the Sun ld command is being used. Anyone seen this problem and know the solution?

APW If I directly call gcc -fPIC on sparc solaris 2.8 gcc version 2.95 and 2.9 gcc version 3.2 there is no problem with -fPIC also in linking. Maybe it helps using: CC=gcc make all then gcc should be used for linking and that works on my machines.

LV After more emails with the user, what I suspect happened is this. Tcl/Tk were changed a bit ago to default to gcc unless the CC variable is set. Not all Tcl extensions have this arrangement. This means that if you don't specify the compiler, some pieces will default to gcc and some to cc. And on Solaris, that situation would cause the situation that the user is seeing - some extensions attempting to use -fPIC and some not. And, if the extension's configure tries to use Tcl's (installed script setting various compile time options) that will pollute the situation. I suggested something similar to APW. Do a make distclean, export the CC environment variable set to the compiler to use, then build Tcl/Tk/Itcl (or whatever else to use) and that should fix the situation.

Of course, the first thing I suggested was to check out the ActiveTcl binary distribution ;-)

schlenk Building the 8.5.0 RC2 on opensolaris (actually Solaris DevExpress for x86 09/07, which is svn_70) i had to go through some bad surprises, but got most things working.

I built with the Sun CC.

  1. --enable-dtrace does not work, because /usr/sbin/dtrace its broken in that version of solaris
  2. Failed tests for expr due to
  3. --enable-xft needs manual help, the system barfs, because it has a broken x11.pc file. (workaround see: )

To fix the xft config issue:

  • Apply the workaround from the above link, creating your own x11.pc file
  • Set PKG_CONFIG_PATH to the dir where the x11.pc file lives
  • Set CPPFLAGS="-I/usr/X11/share/include" because the xft header live there
  • Run configure

After that it finally builds and works.

marcelj - 2011-02-02 13:47:52

I'm fairly new to the Tcl/Tk world, but I've been cranking along with it in Cygwin... love it! I tried using one of my scripts on Solaris 9 & 10 with the same results... Both Solaris environments are using the pre-built binaries installed in /usr/sfw [package require Tk] fails with "can't find package Tk"... this is easily reproduced at the tclsh prompt... I noticed there is no pkgIndex.tcl (for Tk) and created one in the existing tk8.3 sub directory...

   if { [package vcompare [package provide Tcl] 8.3] != 0 } { return }
   package ifneeded Tk 8.3 [list load [file join $dir ..] Tk]

Now, the [package require Tk] returns with the correct version, but no . window is ever displayed... not even from a subsequent pack command... I'm beginning to suspect the was not built correctly for these binaries (to be loaded by tclsh), though wish appears to operate just fine...

IDG What is your exact patch level? Tk became a loadable package in 8.3.4. (see )

marcelj - 2011-02-02 14:56:32

Ah, that explains it...

   % info patchlevel