Well, yeah ok i admit i probably got a bit carried away there. By the looks of it the problem is a tcl problem anyway. the relocation error looks like my tcl is not linking properly.So I should probably be peeved with tcl, not aolserver.

I got tcl 8.4.2 which is supposed to be a stable release, and i did build it with enable threads, etc. The tcl 8.4 .2 did compile flawlessly and only failed one of its self-tests out of 8000 or so - it was some file handling test or other...

I also compiled tk8.4.2, even though aolserver does not require tk... and tk8.4.2 compiled fine but failed many of its tests... many worked, but there were a lot of failures.

As you say, tcl is supposed to be a mature and stable proudct as well, so i am disappointed with 8.4.2 so far... as the third release in the 8.4 series it should be ok, even if it was only released a few days ago. But i despise tcl anyway so I am not surprised. I will try 8.4.1 anyway.

I have lost the configure commands that I used to build tcl from my history, due to the demented way in which mulitple gnome-terminals mangle one's history, by reading it in when they start, and not writing it until they exit.. ie if you start 2 terminals, do a lot of commands in one, then exit it, it will write your commands into the history file. But if u then exit the 2nd terminal, it will overwrite the history with its version which has none of the commands you just did in the other terminal.... Anyway, I recall that the only additional option i used was to enable threads.

Anyway, the aolserver build actually seemed to go fine. I configured the build with:

./configure --prefix=/usr/local/progs/aolserver-cvs --with-tcl=/usr/local/tcl/tcl8.4.2/lib

I made /usr/local/progs/aolserver a link to aolserver-cvs.
Then i installed the nssha and nsxml modules, but no luck.

Regarding the AOLserver build, it was unclear to me whether it was still necessary to apply the patch for ns_uuencode to work with binary files and/or the patch to make aolserver work with the -g flag. The instructions on what to do with the patches from sourceforge are rather unclear... so i am hoping they are no longer needed with AOLserver4

Ill see how i go with tcl8.4.1 and report back.

sorry if it was a bit unclear but the reason i posted that bit re gdk_imlib etc becaus teh linking probs with that library were resulting in a relocation error which at first looked similar to mine:

--------------------------------------------------
On Fri, Jul 26, 2002 at 07:18:49AM -0600, Don Allingham wrote:
> I have been fighting the problem for quite a while, and I cannot come up
> with a workable solution. Under Mandrake 8.2, I keep getting the
> following error:
>
> /usr/bin/python: relocation error: /usr/lib/libimlib-jpeg.so: undefined symbol: _gdk_malloc_image
>
> Things work fine under RedHat, SuSE, debian, any other distribution that
> I or anyone else has tested. I can get around the problem by using
> LD_PRELOAD, but this isn't a really good solution, as it is not very
> portable.
>
> export LD_PRELOAD='/usr/X11R6/lib/libX11.so /usr/lib/libgdk_imlib.so.1 /usr/lib/libgdk.so'
>
> I've tried forcing a load of GdkImlib, but this doesn't seem to have an
> effect. The first call to any image handling routine, either from python
> or from libglade, causes python to abort.
>
-------------------------------------------------

undfortunately in my case libtcl8.4.2.so should not need to link to anything else to get TclCompileScript anyway, all it shoudl need is:
: jss: 22:41:30 /usr/local/src/gui/tcl/tcl8.4.2/unix ; ldd /usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so
    libdl.so.2 => /lib/libdl.so.2 (0x400b4000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x400b7000)
    libm.so.6 => /lib/libm.so.6 (0x400ce000)
    libc.so.6 => /lib/libc.so.6 (0x400f0000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

So it is still beyond me why TclCompileScript (ie TclCompileScript@tclByteCodeType) cannot be found in libtcl8.4.so itself. the LD_PRELOAD wont work in my case because there is nothing i can preload to define TclCompileScript before it is needed in libtcl8.4.2.so because it should be IN libtcl8.4.2.so !!

ldd /usr/local/progs/aolserver/bin/nsd
    /usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so => /usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so (0x40016000)
    libnsd.so => /usr/local/progs/aolserver-cvs/lib/libnsd.so (0x400b8000)
    libnsthread.so => /usr/local/progs/aolserver-cvs/lib/libnsthread.so (0x40105000)
    libdl.so.2 => /lib/libdl.so.2 (0x4011f000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x40122000)
    libm.so.6 => /lib/libm.so.6 (0x40138000)
    libc.so.6 => /lib/libc.so.6 (0x4015a000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


nm /usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so | egrep TclCompileScript\|tclByteCodeType
0003ab40 T TclCompileScript
00099778 D tclByteCodeType


now i am really confused ... the damn thing is actually there...

i cut back my LD_LIBRARY_PATH to nothing to reduce the paths searched (as i only need LD... set for the visualisation toolkit) and the result was:

: root: 00:32:36 /root ; strace /usr/local/progs/aolserver/bin/nsd -t /home/nobody/web/vorpal/vorpal.tcl -u nobody -g web 2>&1 | grep -i libtcl
open("/usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so", O_RDONLY) = 3
open("/usr/local/progs/aolserver-cvs/lib/libtcl8.4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/tcl/tcl8.4.2/lib/i686/mmx/libtcl8.4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/tcl/tcl8.4.2/lib/i686/libtcl8.4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/tcl/tcl8.4.2/lib/mmx/libtcl8.4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so", O_RDONLY) = 3
: root: 00:33:36 /root ;

so it does find it in the end!

well,

my humble apologies to all those whose time has been wasted trying to help me overcome the consequences of my own stupidity.

I recompiled tcl8.4.2 after doing a make distclean to clean up the mess caused by calling doing configure for tcl8.4.2 with:
--prefix= /there/should/be/no/space/b4/this/path

and then configuring again with:
--prefix=/much/better/with/no/space/b4/this/path

It still amazes me that this seems to have been the cause of all my problems... i mean, really, is it too much to expect that calling configure a 2nd time with new options should overwrite all products of previous configures with the new results, without having to do a make distclean???

oh well.

I also tried compiling AOLserver4 CVS against tcl8.4.1 and yeah, no problems there either.

A final comment is in order though. I still would not have a working AOLserver were it not for the fact that I was able to scavenge a copy of nsrewrite.so from the build I did of Matts AOLserver distribution. My CVS checkout of AOLserver4 did not come with any code for nsrewrite.so, and the nsrewrite module is NOT available at sorceforge with all the other modules for AOLserver.

Besides that the only very minor problem was that the sample openACS config file at:

http://openacs.org/doc/openacs-4/files/openacs4.tcl.txt

does not mention that openACS also needs AOLserver to load the nsdb module -- so it needs to have the line:

ns_param  nsdb            ${bindir}/nsdb.so

added at the appropriate place.

Sorry again to all those whose time was wasted especially those who took the time to try to help me.

john