Hi,
I received 3 responses on this question(s), but unfortunately no resolution.
One respondent, Didier Godefroy, will be trying the same effort in the
near future. Hopefully he will have better success.
Thanks for all the responses.
Tom Duffy
PS: Below is a breakdown of the original notes I sent and the responses
that I got.
-----------------------------------------------------------------------
Original Note:
"I've attempted to compile the Tripwire ASR 1.3.1 version on my OSF1 V5.1
alpha machine. I received a series of cc: Info warnings of the form:
config.lex.c, line xxx (e.g. 768): In the initializer for
yysvec[x].yystoff,
an array subscript expression is either less than zero or greater than the
largest value that can be represented by the size_t type. (badsubscript)"
-----------------------------------------------------------------------
Responses:
There was no resolution to this error.
-----------------------------------------------------------------------
Original Note:
"I was able to build with the above errors, so I tried running the make test
command. When I did so, my test suite aborted with the message
"test.update.sh: test FAILED! (expecting 2, got 10)". This seems identical
to the problems noted below in the archives:
http://aa11.cjb.net/tru64_unix_managers/2001/03/0065.html
http://aa11.cjb.net/tru64_unix_managers/2001/01/0367.html"
-----------------------------------------------------------------------
Responses:
Others have experienced the same problem with no resolution. It was
pointed out to me by Uwe Richter that the "Unaligned Access" errors
that are output when Tripwire is run can be disabled via executing the
"uac p noprint" command prior to executing the file check and turned
back on via the "uac p reset" command. The Tripwire code is not "64-bit
clean" which causes the errors/warnings. The uac command cleans up the
output when you run the make test Tripwire self-check, however, getting
Tripwire ASR to work seems to be difficult at best.
Brad Settles noted he had similar issues and provided an alternative
solution: "...I finally decided to use an open source perl script called
fcheck.
(
http://www.geocities.com/fcheck2000/fcheck.html )
It's simple and it works quite well."
-----------------------------------------------------------------------
Tom
Thomas Duffy
Northrop Grumman
> *Phone: 410-993-6128
> *FAX: 410-765-6286
> *Email: tduffy_at_northropgrumman.com
> *Mail Stop: 3J18
>
>
Received on Wed Mar 19 2003 - 14:06:34 NZST