Note: This project is currently on hold.
The reason for this is that I'm working on porting GT.M to Win32.
After that I will clean up the perl stuff so it's ready to be an optional component of the main GT.M tree.

Overview | Download | Documentation | Contact | Customized Perl | Future | License

Stefan's (oesi's) Perl enabled GT.M Tree

This is the official site about the inofficial Perl support for GT.M.
If you never heard of GT.M - it's a great hirachical database made by Sanchez -
available including source code under GPL.

This page is all about Perl support for GT.M - about running GT.M and Perl in the same address-space - about the interaction between GT.M and Perl.

Read this for documentation about embedding Perl in GT.M.
Read this for information about embedding GT.M in Perl, look at to see how to access globals from Perl - it's not much slower than the GT.M version primes.m.
An even more cool version ties the global to a perl hash (using GTM::GlobalTie),


Here is the ChangeLog, please read it first.
Patches here are not what I would call stable so don't use it on production systems without extensive testing.
Here is the latest patch gtm_V44004_linux_i386_src-perl-45.diff.gz
Here are some older, obsolete revisions:


The following man-pages are currently available:


Please report all problems with this module to Stefan Traby <>.
This tree is not stable yet, but I'm working on it and we plan to use the stuff on about 180 production systems.
I'm open to discussions - you can direct feature-requests directly to me.
I'm also willing to support you if you have problems installing this module - if it's not too time-consuming.

Creating your own Perl especially for GT.M

Well, you can use your system Perl - but I suggest to build a Perl for GT.M separately.
The reason for this is that most system Perl's have threads in it - and Perl threads are fundamentally broken by design - they are slow and they act like the fork-model by default - they share nothing.
It's for example not possible to create an anonymous subroutine in one thread and to use it afterwards within other threads.
If you use GT.M with embedded thread-enabled Perl, call GT.M functions just from one thread.
I heavily suggest to use Marc Lehmanns Coro module instead of threads.
I also suggest to not use use64bitint on 32 bit architectures.
It works, but it makes the stuff 20% slower.
I use Perl 5.8.3 self-compiled for GT.M and I install it under /usr/gtm-perl/.
Here - just for reference - how I configure my Perl -
Note: It's important to know that Perl-enabled GT.M uses the compiler that Perl used for building Perl - and also the CFLAGS that Perl used.
This can cause trouble on Perl systems that are built by newer gcc compilers - they have no support for varargs.h anymore - which is cool because varargs.h is obsolete since about 15 years.
I hope that Sanchez will address this soon.


Here some of my plans related to Perl support within GT.M:


All the stuff here is available under GPL.
If you need a different licensing, contact me.
     Sanchez Computer Associates, Inc.
     40 Valley Stream Parkway
     Malvern, PA 19355, USA
is allowed to do with my Perl-stuff what ever they want.