From: (Peter Prymmer)
Subject: Perl/Tk portability.
Summary: Perl/Tk on other platforms?
Date: Thu May 9 21:37:09 EDT 1996
Version: DRAFT

Peter Prymmer's primer pertaining to pertinent Perl/Tk platform porting politics (perchance policies?)

Tk icon
Wouldn't it be great to be able to take my favorite X-clock/file-browser/calculator and run it on any computer?
- anonymous
You can't play if you don't hack.
- even more anonymous

Intro. | License | Ingredients | Cookbook | Efficiency | Platforms | Misc.


It is the stated goal of Nick Ing-Simmons to turn John Ousterhout's Tk X-toolkit into ptk the portable X toolkit. From the Tk-b11.01 README file:
pTk sub-directory is a modified version of Tk4.0p3

It has been modified to call "glue" functions rather than use libtcl.a - so it
is completely independant of TCL.

A goal is to have pTk directory and its library usable from 
perl/Tcl/LISP/c++/python etc.  - perl is 1st.

There are still serious snags with the others.
So the stated goal is to eventually port to other languages.

How about the more modest goal of porting the Tk extension to perl5 to the widest variety of platforms (other than Un*x)? That is the issue that this document attempts to address. Please note that this document is a collection of rumours and slightly out of date material - please exercise extreme caution in the use of the information contained herein. For more up-to-date information subscribe to the mailing list, by sending the message:

    subscribe ptk (Joe User)
to Majordomo@lists.Stanford.EDU.

[BTW, There are no "answers" here - mostly pointers to other sources of useful information. I'm afraid you still have a lot of work to do :-)]

Nick Ing-Simmons has already mentioned the steps involved in such a port

Licensing issues

X is covered by some sort of license. The phrase "X Window System" was originally copywritten by the Massachusetts Institute of Technology. I don't know, but perhaps the X Consortium has dibs on that phrase now.

Perl is copywritten by Larry Wall. Here I am reproducing a copywritten statement from the Camel (pp 433):

Perl is copyrighted, and is thus not in the public domain -- it's just freely available and freely redistributable (q.v.).
Perl is covered by a couple of licenses (GPL and Artistic). Here is the README file that comes with perl5.002. There is also the Artistic file that comes with perl5.002. Anyone seriously considering working toward the advancement of perl ought read those files carefully, very carefully.

Nick Ing-Simmons' ptk and assorted code is covered by copyright notices too:

Copyright (c) 1995 Nick Ing-Simmons. All rights reserved.
This package is free software; you can redistribute it and/or
modify it under the same terms as Perl itself, with the exception
of the files in the pTk sub-directory which have separate terms
derived from those of the orignal Tk4.0 sources and/or Tix. 

See pTk/license.terms for details of this Tk license, 
and pTk/Tix.license for the Tix license.
Anyone seriously considering working toward the advancement of perl/Tk ought read all the files mentioned thus far carefully.

Necessary ingredients

The absolute minimum you need is a C language (or C++) compiler. It is tremendously helpful to have a few other things as well. The short list is: a C-compiler, Xlib, perl5, the Perl/Tk kit, and a make utility (preferably one that is amenable to a MakeMaker port to your system).

C language compiler

../gif/C_icon.gif Has gcc been ported to your platform? If so you are in luck as it is a C compiler most forgiving of coding mistakes and/or "unconventionalities". However, it should be possible to port perl and perl/Tk to any platform's C compiler.

Does your platform's C implementation (compiler & linker) support dynamic linking? If so that would be a plus, but it is not necessary. Having a C compiler (or a C++ compiler that can reasonably handle C) is necessary. If all you have is a C++ compiler that may be OK since a great many C++ compilers can pretend that they are C compilers.

ANSI-ness is not as big a deal as you might imagine. If you wind up building everything (including libX11 and perl) using your C compiler then everything ought to work even if your compiler is not ANSI compliant. It is a great idea (you _must_?) build Tk using the same compiler that you used to build perl. If you are lucky enough to be able to use MakeMaker with your perl then the correct C compiler will be invoked from the Makefile when you type the make command.


img/xlogo64.gif Recall that X started in about 1984 to be the platform independent interface thingy. It is supposed to work everywhere - yes even on your PC/AT, and even on your Mac (<- on the Mac X even works with DECnet transport protocol [though tcp/ip is much more common]!).

Here are some interesting excerpts from X Window System C Library and Protocol Reference by Robert W. Scheifler, James Gettys, Ron Newman, Al Mento, and Al Wojtas (© 1988 MIT and DEC ISBN 1-55558-012-2):

The X Window System, or X, is a network-transparent window system...that was designed at MIT.
It runs under ... several operating sytems.
Xlib is a C subroutine library that applications programs (clients) use to interface with the window system by means of a stream connection.
Please note that while much X documentation refers to "X toolkits" (e.g. Xt, Xm, Xmu, etc.) such toolkits are typically front ends to C subroutine libraries. Hence those "toolkits" are typically called from some other compiled language (which is usually C or C++). Tcl/Tk and Perl/Tk are a bit more than mere "toolkits" in that they allow access to a good deal of Xlib functionality via the other languages (Tcl and Perl respectively). [BTW there also is a Lisp version of Xlib that you need not concern yourself with in an attemp to port Perl/Tk.]

Take a look at "Getting X" from the folks who write and maintain it. They (the X consortium) also have a page on Writing Portable X Code which is a must read document. You should probably check out the Xlib man pages too.

Perl/Tk can be built on Unix platforms under X11 R5, R6, and R6.1. I do not know if it has been built with prior releases.

The critical Xlib files include: the sharable image libX11.a (or, or LIBX11.EXE, or whatever name.extension your system uses for this type of file), and the header file Xlib.h (as in #include <Xlib.h>).

Perl 5

../img/camel.gif You want the object oriented perl5 - the fresher the better (by that I mean try to get a very recent version). Perl 4 just will not cut it. Find a CPAN ftp site near you.

A "make" utility

 make - Maintains up-to-date versions of target files and performs shell
On Unix platforms the standard make utility uses a Bourne shell type syntax for carrying out compiling and linking of (usually complicated) source code. There is also a GNU make utility called gmake - has it been ported to your platform? Does your C compiler have "project files"? (These are equivalent to Makefiles.)

On VMS there is a commonly used MMK utility that uses a DCL shell syntax.

I would presume that a MacMaker could use AppleScript(?), a DOS|WIN|OS/2 maker would use a CMD *.BAT file (or Rexx?), etc.. On the microcomputers there are also commercial C compiler IDE's that do the equivalent of make with .c and .h code typically using "project files". (You might want to disentangle yourself from the non-transportability and awful licensing issues involved with these IDE's though.)

How good is your platforms' port of perl5? MakeMaker? Basically will:

    perl Makefile.PL
"work" on your platform (i.e. create the right type of Makefile [or equivalent])? This question involves the platform specificity of the Extutils::MakeMaker module. Note that there are,, and modules to help on those platforms. To help develop on your Foonix platform, consider subscribing to the MakeMaker mailing list

Can your platforms' perl port turn .xs into .c and .h? In other words is your h2xs and xsubpp working? Either of these perl utilites may require some modification for use on your system. With modern perl's one can make very effective use of statements like the following within the perl code:

    use Config;
    if $Config{osname} eq 'VMS' {
        # VMS stuff goes here

Your perl5 Autoload utility should be working too (if your C compiler does dynamic linking). How about ExtUtils::Mkbootstrap?

Perl/Tk kit

X Camel Pick up a version that corresponds to the version of perl you will be using. Failing that pick up the latest release. Either should be available on CPAN.

other things

../gif/Tcl_icon.gif Has Tcl/Tk been ported to your platform? If so you might consider looking through the relevant READMEs and/or Makefiles for that software package as a guide to understanding how to port Perl/Tk to your system. (Hint: you want to try to compile it on your machine. In other words, do not simply pkunzip a WISH.EXE file.)

GNU X How about the xmkmf program or the patch program? They would be useful (but are not necessary). The previously mentioned gmake program would be useful on any system. It may have been ported to yours.

Of course dealing with file distribution can be a portability problem in its own right. Perl code is typically distributed from CPAN sites via binary mode ftp of *.tar.gz files. Hence you need: ftp, tar, and gunzip. Note that the gunzip program is different from unzip and different from pkunzip.


Your goal is to reduce it to something simple like:
    perl Makefile.PL
    make test
    make install
But of course, some ports do lose (or gain) a little in the translation. On systems whose C-compiler only supports static linking making the static version (perhaps via "make tkperl" after "make" and before "make test") would be great too.

The first of these build steps (perl Makefile.PL) is the MakeMaker step and strictly speaking is not necessary if you can figure out an alternative means of quickly putting together a Makefile (or project file, or whatever) for not only this version of Perl/Tk but all subsequent versions. (In other words hacking away with a text editor to come up with a Makefile for Tk-versionX to compile means that anyone making use of your port of Perl/Tk will be stuck with -versionX, meanwhile everyone else will have moved on to -versionX+1). On Unix systems the Makefile.PL script that comes with the Tk module calls the myConfig perl script to query the computer (actually the xmkmf program) about where it's Xlib libraries and headers are. So where on your system is libX11.a (or, whatever)? Where on your system is the Xlib.h file? These are the types of questions that need answering when trying to compile the Tk extension to perl on your system.

The second of these build steps (make) is the compile, archive/library objects, and link step and must of course be translated into your platforms' C-compiler-and-linker's native format. As hinted there is an optional make tkperl step for statically linked compiler/linkers [of course this target may or may not be in your Makefile depending on whether you have a Makefile].

The third step (make test) really only runs the widget demo script to make sure nothing has gone wrong. On Unix systems the Makefile is set up with dependancies such that typing make test will do a complete make if it had not already been done. On a port to a system much different from Unix it would not be at all unreasonable to ask people to simply run the widget demo using perl in whatever fashion it is invoked on your system.
On Unix the make install step copies the code over to a special perl installlation directory. This step may be unnecessary on your system.
In sum: the make step of compiling (cc) object collection (ar) and linking (ld) is most critical [so tricky in fact that that is why the make program was invented!], the first step is simply an automatic way to get perl to set up the Makefile for you (and probably should not be overlooked by you).

You can of course read a detailed description of how to build Unix Perl/Tk in the appropriate entry in the Perl/Tk FAQ.

Nick Ing-Simmons has outlined the steps necessary to port perl/Tk to other (non-unix) platforms:

Re: Perl/Tk for NT

Nick Ing-Simmons (
Fri, 12 Jan 96 08:54:30 GMT

In <>
On Fri, 12 Jan 1996 09:22:56 +1030
Matthew Phillips <> writes:
>I'm very impressed with your Perl/Tk package and am hoping to be able to
>use it for the GUI implementation of our next project. However, we need
>to be able to run on Windows NT primarily, and UNIX (Solaris) at a later
>date. I know there is an NT Tcl/Tk port, but what are the odds of a
>Perl/Tk port? If there isn't one, how difficult would it be for a
>reasonably experienced UNIX hacker to convert the NT Tk package to be
>usable via Perl 5?
>Keep up the good work!
As far as work time goes I can justify (some) time spent on UNIX
perl/Tk. An NT (Win32) port would have to be a home (hobby) project,
and I don't have (or particularly want) an Win32 machine at home.
(My home machine is a dual CPU SPARCStation10,Solaris2.4.)

What 'we' need is a "reasonably experienced _NT_ hacker":

What I need is someone that understands Win32 (or OS/2 as may be),
to figure out issues like DLL/OLE (which is just an acronym to me).
I could learn this stuff of course - guess I will some day - but don't
have the time to learn it now. Anyone who knows they need the port
knows more than I do in this area.

The steps are :

1. Build Perl for your environment - I think you need to re-compile
from sources. This may be ntperl or via gcc-win32 or however.

2. Work with me/porters to incorporate a "trivial" C extension to this perl,
to see what is involved - we can do this 'static linked' if this

3. Build John Ousterhout's Tcl/Tk4.1a* for your environment, so that we
understand what it can do and bits that need to be there.

4. I apply my tk4.0 vs perl/Tk diffs
to 4.1a and run all the C files though my munging perl scripts.
I then have a UNIX 4.1a - my guess it might take a day or two.

5. Do same things as (4) to bits of 4.1a that UNIX does not use, based on
understanding developed in (3).

6. Then compile all those, iterate munging/compile as required.

7. Apply the "how do we add a C extension" lessons from (2) to objects
from (6) to get perl/Tk executable(s).

8. Sort out inevitable filename/UNIXisms issues in *.pm files.

I can do (4) almost anytime. But there is little point unless someone
is going to use it soon as otherwise it will have to all be done again
if a new Tk4.* comes out...

Well that is what Nick had to say about WinNT|Win32|OS/2 in particular - but of course the methods described are equally applicable to any other platform.

For help in understanding what is involved in Nick's step number 2 above consider working through the example given in the perlxstut man page (as well as perlxs(1) and the pod docs for MakeMaker.)

In step number 4 Nick is referring to the Unix diff program that tells you the difference between two files (usually text files). The output of diff are the "diff files" that Nick is referring to. The inverse of the diff program is Larry Wall's patch program (which is also distributed separately as a GNU utility - unfortunately not as a perl script!). Do you have a patch program on your system that would allow you to apply Nick's diff files? If you do not then you will need to do a lot of hand editing (it is possible to simply read diff files - they are plaintext).

Note that on the perl Makefile.PL step (under Unix) it is sometimes necessary to give explicit locations of the required X11 libraries and/or include headers. For example, if libraries and headers are in one location (that the xmkmf program cannot find) then:

    perl Makefile.PL X11=/usr/local/X11R6
or, if the headers are in one place and the sharable libraries are in another place then:
    perl Makefile.PL X11INC=/usr/local/share/X11R6/include \
Where the Unix line continuation character "\" has been used to split the long input (that is the tcl line continuation character too :-). Hence, on VMS it should be possible to say:
    perl Makefile.PL X11INC=SYS$SYSTEM: -
and have a DESCRIP.MMS file pop out! (Unfortunately perl has different ideas about what $SYSTEM and $LIBRARY mean on that system.)

Nick has also recently commented on the primary differences between the Tcl/Tk code and his Perl/Tk code.

Porter Efficiency

If programming was easy, they wouldn't need something as complicated as a human being to do it, now would they?

Read the Camel...

Testing your system

Herein follows a discussion of a simple C program that uses X and contrasts it with an equivalent simple perl script, a simple wish script, and a simple perl xs subroutine. Following any or all of these steps ought to help you uncover problem areas for compiling perl/tk on your system. The discussion of the xs extension might also help folks who wish to write their own widgets.

Lesson 0: hiworld.c
In an effort to test your ability to port and use Xlib on your platform consider writing and compiling a very simple C program that uses Xlib. For example hiworld.c. On a typical UNIX computer I can compile and link that program with a command like:

    cc hiworld.c -lX11
whereas if I used the GNU C compiler that would simply be:
    gcc hiworld.c -lX11
(and you may need other -l or -L arguments depending on the details of your system.)

It is amusing to note that the equivalent functionality of that roughly 73 line C program can, with Perl/Tk to the rescue, be written in about 10 lines:

    #!/usr/bin/perl -w
    use Tk;
    my $m = MainWindow->new;
    my $c = $m -> Canvas(-height => 200, -width => 300,);
    $c -> pack;
    $c -> create('text', 40, 50, '-text' => "Hello World!");
    $m -> bind('<Any-KeyPress>' => sub{exit});
    $m -> bind('<Button-1>' => sub {
        $c -> create('text',$c->XEvent->x,$c->XEvent->y, -text => "Hi.") });
(Note the tcl/tk version is only 6 lines!, neither of which is really fair to the C version since it cannot even refresh the additional "Hi." strings on expose events the way the perl and wish scripts do automatically.)

Lesson 1: Makefile
Assuming you are able to figure out how to compile and link hiworld.c, an additional step to take would be to try coming up with a Makefile for it (although this would not be necessary if you have MakeMaker and can follow the steps in Lesson 2 below). The crude way to create a Makefile is to simply use a text editor to write something like this:

    hiworld : hiworld.c
            cc -o hiworld hiworld.c -lX11
which would be invoked with "make hiworld" for example. It is considered much more fashionable to throw in a bunch of macros into one's Makefile's as in the following:
    CC = cc
    X11 = -lX11
    all : hiworld
    hiworld : hiworld.c
            $(CC) -o hiworld hiworld.c $(X11)
which is still invoked via "make hiworld" even though it looks a little more complicated.

Lesson 2: h2xs, xsubpp, hiworld.xs, Makefile.PL
The point of this exercise is not to show how to "add X routines to perl" (even though that is what it does). The point is to illustrate the use of h2xs, xsubpp, ExtUtils::MakeMaker, et al. Please note that each of these useful perl utilities may or may not have been ported to your system. If not then see if you can lend a hand in doing the port.

Following the perlxstut(1) man page we go to an otherwise unused directory and type:

    h2xs -A -n Howdy
and note the creation of a new Howdy directory with four new files: Howdy.xs,, Makefile.PL, and MANIFEST (with later versions of h2xs there will also be a and a Changes file).

To get our Xlib code into Howdy we will need to append (and slightly modify) the contents of hiworld.c to Howdy.xs (on Unix that would be something like cat hiworld.c >> Howdy.xs.) We edit Howdy.xs to add the required CODE: and OUTPUT: RETVAL statements, as well as to change function main(argv argc) to a funtion hiworld(argv argc) (clever name eh?). So that now the head of Howdy.xs appears as:

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include <X11/Xlib.h>
#include <X11/Xutil.h>

MODULE = Howdy          PACKAGE = Howdy

hiworld(argc, argv)
        int argc
        char argv
(note the function type of int, although void would have been just as appropriate.) The tail of Howdy.xs now appears as:
(note the absence of a call to exit(0);, and an absence of the braces {} for main.)

We turn our attention to the Howdy/Makefile.PL file and change the line that says:

    'LIBS'      => [''],   # e.g., '-lm' 
to read something like what we needed to use to compile hiworld.c from the command line, like:
    'LIBS'      => ['-lX11'],   # e.g., '-lm' 
We can now say
    perl Makefile.PL
    make install
(note that after make and before make install you may be able to make test if you have updated Also, statically linked Howdy perl binaries can be made by running:
    make -f Makefile.aperl inst_perl MAP_TARGET=perl
after make and before make test.) After make install it is possible to run perl scripts that call the hiworld() subroutine in as little as three simple lines of perl:
    use Howdy;
    $return = &Howdy::hiworld($a, $b);
That is all there is to it! For illustrative and testing purposes I have made a distribution copy of the Howdy "module" for perl. [Please also note that a much more extensive discussion of such an extension as a Tk widget building exercise is taking shape as this document.]

You may experience tremendous difficulty in getting any of the above steps to work (they work pretty smoothly on most Unices). Hopefully, by following these steps you will encounter the problem areas that need work on your platform's port of perl. Do not be discouraged - ask around for help.

Of course it should not ultimately be necessary for you to use these techniques (h2xs et al.) in a "standard compile" of Perl/Tk on your system because Nick Ing-Simmons has already packaged everything for you. Trying this test out as a means of uncovering what could possibly cause trouble on linking Xlib calls to your perl ought to help with the port of Perl/Tk to your system however.

Lesson 3: Tk's Makefile.PL
The Makefile.PL that is distributed with Tk is considerably more complicated than the trivial one that we just made for Howdy in lesson 2. Among other things the Makefile.PL with Tk calls external perl scripts that try to call the xmkmf utility on your system. Note that if your system does not have xmkmf you may need to tell perl just where the Xlib stuff is sitting on your system. This is why it is sometimes necessary to say something like:

    perl Makefile.PL X11=/usr/local/X11R6
or, if the headers are in one place and the sharable libraries are in another place then:
    perl Makefile.PL X11INC=/usr/local/share/X11R6/include \
(Another reason that specifying any of the X11 macros may be necessary is to force a choice of one version of X11 over the default that gets specified by xmkmf X11R6 over X11R5 for example.)

The statement within the main Tk Makefile.PL:

    require "./myConfig";    
invokes the myConfig script for snooping out X on your system. Note also that in the Tk*/config directory there are a number of tiny C programs for testing platform dependent things like: signed vs unsigned char's and TIMEOFDAY_NO_TZ.

Tk's Makefile.PL also makes use of the Tk*/Tk/MM*.pm packages for help in making the multiple Makefiles necessary for the complete build.


This collection of information is very informal.

You might find your system mentioned in the ptk hyper-mail archive at:
or the Perl 5 Porters (p5p) page at one of the following URLs:
or the perl metaFAQ (pmFAQ) at
If you wish to discuss your Tk build problems with others run and save the output from the myConfig script in the Tk build directory (the output may already be in the myConfig.out file from your Tk-b# build directory), as well as the myconfig script in your perl build directory. It is often helpful to include the output of either (or both) of these scripts in your discussion.

Presented here are the beginnings of a list of problems* associated with building Tk-b# on various operating systems. Note that a working definition of "UNIX" would probably have to mention something like:

That form of computer operating system which has proven so wildly popular that one (or more) organization(s) has (have) attempted to either sue or demand payment from one (or more) other organization(s) over the use of the word "UNIX".
I am not completely sure if all of the following meet this criterion... (You are welcome to visit a separate page on non UNIX perl platforms if you like.)

(* & successes are marked with an icon - meaning one or more versions of Perl/Tk has been reported to run on the named OS. Conversely, the absence of an icon cannot be construed to mean that Perl/Tk does not run there. The abscence of an icon may merely mean that I missed the announcement of the successful build [if such an announcement was made] :-)

The platform list:

68K: (perhaps your best bet is Mach Ten with X, or MacLinux/MacBSD (?)
img/T_pTk.gif As of perl5.002b & Tk-b9.01 README.AIX says no patching is necessary.

For Tk-b8: modifying the perl.exp file may be necessary. There is a patch in Tk-b8/README.AIX. It may be necessary to make regen_headers after the patch.


Amiga: (see pmFAQ or p5p)
Atari: (see pmFAQ or p5p)
DOS: (see pmFAQ or p5p)
Dynix: (see pmFAQ or p5p)
GNU Hurd:
img/T_pTk.gif For Tk-b11: One person reports a need to add #define TIMEOFDAY_TZ to the tkConfig.h header file in order to compile on HPUX 9.05.

Previous versions: Most people seem to prefer the dynamic linking afforded by a recent version of the gcc compiler on this system.


Human68K: (see pmFAQ or p5p)
img/T_pTk.gif John C. Wingenbach indicates that should you encounter an error message like Cannot find -lX11 anywhere at ./myConfig line 184 when running your perl Makefile.PL (under Slakware 3.0) that you should be more specific about -l/path/to/libX11.a.
Adam Wasserman <> has graciously provided a compilation of Linux compilation trials & tribulations. It is an (as yet un-edited) document available at:


LynxOS: (see pmFAQ or p5p)
Check the ports/mac/ directory at CPAN site [when last checked in January 1996 the binary in this dir corresponded to perl4.036 which is inadequate for the Tk extension :-(]
Matthias Neeracher is leading the effort to implement perl5 for the Mac. There is also a mailing list for MacPerl: send a message body of "subscribe" to <>. The list itself is addressed as <> There is a hypermail archive of the MacPerl list at

There is a FAQ-like question & answer document for MacPerl at: (see also pmFAQ or p5p)

The latest versions of the source code for Tcl/Tk have build directories for Macs.

For Xlib on this platform your choices appear to be limited to commercial packages:

In private communication with Richard Stallman the previous ban on GNU work for the MacPlatform has now been lifted (presumably because of competition it is no longer a closed, proprietary computer platform). However, regarding a port of the latest gcc to the Mac: "we have more urgent priorities".

For Perl/Tk see also Mach Ten.


Mach Ten:
img/T_pTk.gif Mark Pease <> [Co-Author (with Carl Dichter) of Software Engineering with Perl] reports that on his Mac IIcx running Tenon's MachTen 2.2 (BSD 4.3) with a Mach kernel running on top of the Mac OS - it takes 3 hours to compile perl and an additional 5 hours to compile the Tk extension. He managed with Tk-b9.01 using Tenon's X11R5 version 3.1. (Strictly speaking Mark considers this MachTen to be Unix.)

See also Tenon's XTen Home Page (X for power Macs).


img/T_pTk.gif Jesus M. Gonzalez <> mentions success with:
"Tk-b11.01 compiles, installs and runs just out of the box in NetBSD-1.1/i386. I just followed the INSTALL instructions"


Gerd Knops recently posted a discussion of the steps to get perl running on several NeXTSTEPs to p5p.


For perl itself see the os2/README file that comes with perl. Ilya Zakharevich <> recommends a GNU make patch available from
> By the way Ilya - do you have Tk running on OS/2 ?
> Any hints or advice you could lend would be appreciated.

I got the volume 9 of devcon today, maybe I will try to use DAPI to port the windows stuff. I need it badly, but not going to spend a lot of time on this.


Ilya has ported Tk 4.1 to OS/2 and it too is available from:
Here is what the author of the port had to say about it:
It takes ./generic part of the source, and compiles it pretending that it is UNIX using UNIXish CRT. It takes a ./win part and compiles it using Win32/OS/2 libraries (DAPIE).

There are 2 or 3 places where I needed patches to soften the conflicts which obviously arise, 7 symbols intentionally missing in DAPIE, and 3 bugs in DAPIE which I should code around. That's all.

Be sure to see the XFree86/OS2 project page.

If you insist on spending money to do your port then some commercial Xlib alternatives are:


img/T_pTk.gif As of perl5.002b & Tk-b9.01 you will probably be able to follow the usual instructions. John Stoffel <> reports that if you use gcc (rather than cc) you should use at least version 2.7.2

For Tk-b8: make is reputedly not up to the task on this system. Tk-b8/README.OSF recommends gmake instead.
Stephane Bortzmeyer <> reports a successful build with Perl 5.001m, xsubpp 1.922, MakeMaker 4.23. He points out that it was necessary for him to upgrade the xsubpp and MakeMaker that he received with his copy of Perl5.001m.


Perl 5.002 definitely runs on this system.


img/T_pTk.gif For Tk-b8: Eric J. Bohm <bohm@cs.Buffalo.EDU> reported a need to comment out line(s) from myConfig and GNUMakefiles using GNU make 3.67. (See Tk-b8/README.SCO for specifics.)


SGI (Irix):
img/T_pTk.gif Matthew Black <> recently mentioned a need to apply "patchSG0000596" to get perl sockets to work. His message was copywritten and is not included here. Send e-mail to him to find out where the get "patchSG0000596".


img/T_pTk.gif img/T_pTk.gif
SunOS (BSD):
For Tk-b10 on SunOS 4.1.3_U1
using SparcWorks acc 3.0.1 Frederick L. Wagner <> reports needing to use the perl malloc rather than the system malloc() when building perl.
For Tk-b8: Tom Tignor <tpt2@BBN.COM> reports the following on SunOS (sun4m sparc): Tue, 28 Nov 1995 13:19:42
In trying to make, I got a "write: argument mismatch" error for the file ptK/Lang.h. I looked at the file and found the offending function, Tcl_GetOpenFile, which has a third argument called "doWrite" (not "write") in tkGlue.c. I changed the argument from "write" to "doWrite" in Lang.h and it's compiling fine (for the moment. :)

Solaris (System V):
For Tk-b8: There is trouble getting perl to use Socket routines (i.e. trouble with make perl itself not necessarily trouble with Tk-b#). See the perl FAQ for more info or the .shar file that Tom Christiansen occasionally posts to comp.lang.perl.misc. Further information on perl inter process communication can be found in the perlipc* files at:


img/T_pTk.gif For Tk-b8: Martha G. Armour and Len Reed report on two separate hardware platforms running SVR4 - extensive details in Tk-b8/README.SVR4. Interestingly, they report no trouble at all on Linux.
img/T_pTk.gif Peter Prymmer reports that with Tk-b11 it was necessary to change the line in Makefile.PL that reads:
'LIBS' => ["$xlib -lX11 -lpt -lsocket -lnsl -lm"],
to read:
'LIBS' => ["$xlib -lX11 -lpt -lsocket -lnsl -lm -ldnet"],
because of a newer X11 in /usr/local that needed the DECnet protocol linking.

John Stoffel reports a successful build of static Tk-b10 on Ultrix 4.5.


Venix: (see pmFAQ or p5p)
(This one should win an award for the coolest sounding UNIX ripoff name ;-)


Charles Bailey <> has done a wonderful job porting perl5 to VMS. It can be built using MMS, MMK, or VMS GMake or IMake. Not (yet?!) distributed on CPAN it is available from: (Recommendations: do not try anything but a VMS web browser to follow the hyperlink as browsers on other OSes do not grok the protocol on VMS ftp servers too well. If you do not have a VMS web-browser then use line mode ftp instead. Do use an UNZIP specifically compiled for the VMS file system.)

Angel Li has ported Tcl7.5a2 and Tk4.1a2 to VMS and maintains a web page at


Win 95:
(see Win NT, DOS, or the page at:


Win NT:
Gary Ng <> is currently working on an NT port of perl5.002. For a C compiler he uses VC++ 4.0, but adds that there is a RSXNT which allows you to run emx port of gcc (2.7.2). "It is great for porting unix utilities."

Be sure to check out Cygnus' gnu win32 stuff.

The hip port was conducted under contract with Microsoft corporation
See hip info on (perl5 only no Tk extension) at: There is a mailing list for hipsters at: <>.
There is also a mailing list for users at: <>.
There is a moderated mailing list for announcements at: <>.
Questions concerning any of these lists can be addressed by sending e-mail to: <>. To unsubscribe from perl-win32-users send a message of unsubscribe perl-win32-users to <>.
If you are still having trouble with that list try sending e-mail to <>

Unfortunately, the hip NT Perl FAQ mentions:

The NT Perl unsupported page mentions: The Win32 info page mentions: Be sure to see also the OLE extension to NT Perl!

The latest versions of the source code for Tcl/Tk have build directories for PC-style microcomputers.

Nick Ing-Simmons has recently (Jan 96) commented on the steps necessary to get perl/Tk running on these sorts of platforms. Check out:

Apparently on this platform a pre-packaged Xlib is something that people are only willing to charge you money for. There are a number of commercial X packages for this platform such as:


Xenix: (see pmFAQ or p5p)
Note that hints files exist for the following OSes for compiling perl5 with Configure:
3b1             dynixptx        irix_6_2        next_3_0        sunos_4_0   
aix             epix            isc             opus            sunos_4_1   
altos486        esix4           isc_2           os2             svr4   
apollo          fps             linux           powerux         ti1500   
aux             freebsd         machten         sco             titanos   
bsdos           genix           machten_2       sco_2_3_0       ultrix_4   
convexos        greenhills      mips            sco_2_3_1       unicos   
cxux            hpux            mpc             sco_2_3_2       unisysdynix   
dec_osf         i386            mpeix           sco_2_3_3       utekv   
dgux            irix_4          ncr_tower       sco_2_3_4       uts   
dnix            irix_5          netbsd          solaris_2   
dynix           irix_6          next_3          stellar


OK here is a bunch of info that simply would not fit easily into any of the above categories. Maybe some of this is useful...

Be sure to check out the Xlib man pages. See the PIGUI FAQ for more information. There is also the FAQ. There is a Widget FAQ too. There is also Kenton Lee's excellent Xsite page. Zona Research Inc. provides a X news sub$cription service. Whereas the The X Advisor Home Page appears to be free (for the online version at least). Be sure to pay an occasional visit to the X Window System page at Yahoo for the latest hype[r]link.

Here are the some of the many fine people that distribute X for free (the way it's authors and copyright holders intended):

There are a number of commercial vendors of X code that tout "platform independence" more strongly than does the X consortium itself among them these organizations that typically offer Xlib for sale (usually to microcomputer users) [some have free demo versions available]: Here are some X related newsgroups: Slightly unrelated X newsgroups include:


also known as. aka a.k.a.
A Computer language (it is compiled).
C compiler (the one your hardware/software vendor sold to you, as opposed to gcc). Also, the typical name of the program that does the compiling of C programs on your system (it may do more).
a usenet newsgroup for discussion of Perl/Tk. aka
a usenet newsgroup for discussion of Perl/Tk. aka
Central Processing Unit.
Dynamic Link Library: available on the Windows platforms, OS/2 (others?).
exempli gratia.
et al.
et alii.
et cetera.
The GNU C compiler.
Four Letter Acronym Name. Also, a delicious custard-like dessert
Gnu's Not Unix. (That's a recursive acronym in case you missed it).
Graphical User Interface.
Integrated Development Environment. Usually an expensive compiler/maker/language-sensitive-editor package for microcomputers.
computers that employ the hardware designs of the popular Motorola or Intel/AMD/Cyrex CPUs. Examples include MacIntoshes and PCs. Operating systems include linux, MachTen, NetBSD, Qnx, and FreeBSD.
Massachusetts Institute of Technology. An institution of higher learning for primarily technical fields of study in Massachusetts USA.
Object Linking and Embedding A cross-platform object (usually a GUI thing) brought to you mainly by Microsoft Inc.
practical extraction and report language, or pathologically eclectic rubbish lister.
The left side of a ship when onboard and facing the bow (the forward moving direction assuming the ship is moving forward).
One who carries or "ports" from one place to another. e.g. The passenger platform of the 53rd street pier to the Champagne suite on the "Sunshine Deck" (Sun DEC?).
portable Toolkit, or pure Tool kit, or a mailing list devoted to an interpreted GUI programming language.
a University in northern California (between San Jose and San Francisco). Where the W library was developed along with the V operating system.
Tool command language. (Not to be confused with Perl.)
An (american?) english term for that which is difficult to name or remember the name of. aka thingamabob, thingamajig, doo-hickey, etc.
Texas Instruments.
Tool kit.
[Two|Three] Letter Acronym.
United Kingdom.
The letter after W. Don't laugh! If you read your X-history you will see why this is not such a dumb definition.
A component of a bitmapped display or GUI. Examples include Buttons, Scrollbars and the like.
Worcester Polytechnic Institute. An institution of higher learning for primarily technical fields of study in Massachusetts USA.

Intro. | License | Ingredients | Cookbook | Efficiency | Platforms | Misc.

I am:
Peter Prymmer
Wilson Synchrotron Laboratory
Cornell University
Ithaca, NY 14853 | perl/Tk FAQ | FAQ Table of Contents