[AOLSERVER] Has anyone built nsd3.3+ad13 on 64-bit Linux?

0 views
Skip to first unread message

Janine Ohmer

unread,
Nov 5, 2010, 4:58:56 PM11/5/10
to AOLS...@listserv.aol.com
I just posted the following to at openacs.org, and wanted to see if anyone who lurks here but not there might have any ideas:

Due to unforeseen circumstances (server death :) I'm moving some very old sites to a new system running 64 bit Redhat (old system was 32 bit). A couple of these sites were running under nsd3.3+ad13. To my great surprise most of nsd worked without having to be rebuilt, but the postgres driver did not work and I was unsuccessful at building a new one.

Not wanting to invest a lot of time on an ancient webserver, I went ahead with the move and set the 3.2.5 sites up under AOLserver 4.0.10, also quite old but the client didn't want me to upgrade anything more than was absolutely necessary.

Unfortunately, they don't work. There are no errors in the error log on startup but the page load dies with:

invalid command name "template::adp_parse"

There don't seem to be many people reporting this error. I've seen this thread:
http://openacs.org/forums/message-view?message_id=26808

But have double-checked the config file (several times!) and Home is set correctly. However, this makes me think that the problem is probably due to changes to AOLserver's module/tcl scripts.

So does anyone know how to either a) run 3.2.5 under AOLserver 4 or b) get nsd3.3+ad13 built and working on 64 bit Linux?

Thanks in advance!

---
Janine Ohmer (formerly Sisk)
President/CEO of furfly, LLC
503-693-6407


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.

Janine Ohmer

unread,
Nov 5, 2010, 6:03:18 PM11/5/10
to AOLS...@listserv.aol.com
Followup to this...

The original build error was:

(cd /usr/local/src/aol33+ad13/aolserver/tcl7.6/unix; make CFLAGS='-I../include -D_REENTRANT=1 -DNDEBUG=1 -g -fPIC -Wall -Wno-unused -mcpu=x86_64 -DHAVE_CMMSG=1 -DUSE_FIONREAD=1 -DHAVE_COND_EINTR=1' libtcl7.6.a)
make[2]: Entering directory `/usr/local/src/aol33+ad13/aolserver/tcl7.6/unix'
gcc -c -I../include -D_REENTRANT=1 -DNDEBUG=1 -g -fPIC -Wall -Wno-unused -mcpu=x86_64 -DHAVE_CMMSG=1 -DUSE_FIONREAD=1 -DHAVE_COND_EINTR=1 -I./../generic -I. -DHAVE_UNISTD_H=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DSTDC_HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_SHLIB_EXT=\".so\" ./../generic/panic.c
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
./../generic/panic.c:1: error: bad value (x86_64) for -mtune= switch

I fixed this with:

# CFLAGS+=$(GCCOPT) -mcpu=$(shell uname -m)
CFLAGS+=$(GCCOPT) -m64 -mtune=generic

in aolserver/include/Makefile.global.

Now everything builds, but it starts to run and then seg faults. *sigh*

I also tried

CFLAGS+=$(GCCOPT) -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic

(everything from the new Makefile.global that the old one doesn't have) But it still seg faults.

janine

Gustaf Neumann

unread,
Nov 6, 2010, 6:02:59 AM11/6/10
to AOLS...@listserv.aol.com
If you want to compile the vintage version, i would will
have to compile either
with -m32 or to backport the 64bit fixes of the last 10
years, which are most
likely necessary for aolserver33 as well.

Search e.g. through
http://www.ohloh.net/p/aolserver/commits?query=64-bit&commit=Update
http://www.ohloh.net/p/aolserver/commits?query=64-bit&commit=Update
and similar search patterns

best regards
-gustaf neumann

Janine Ohmer

unread,
Nov 6, 2010, 12:24:08 PM11/6/10
to AOLS...@listserv.aol.com
Thanks, Gustaf. I finally abandoned this and got it working (as far as I can tell, anyway) under 4.0.10.

janine

Tom Jackson

unread,
Nov 6, 2010, 1:49:25 PM11/6/10
to AOLS...@listserv.aol.com
Janine,

My guess is that the code was run inside a namespace instead of at the
global level. This makes the proc name relative to that namespace. The
other possibility is that the proc was sourced inside a namespace and
became part of that namespace.

tom jackson

Reply all
Reply to author
Forward
0 new messages