[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
Notice: | Welcome to the Digital UNIX Conference |
Moderator: | SMURF::DENHAM |
|
Created: | Thu Mar 16 1995 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 10068 |
Total number of notes: | 35879 |
9281.0. "xtaso_header_edit behavior in 4.0?" by HYDRA::BRYANT () Tue Mar 25 1997 12:15
I have a partner who played with this script in 3.2 and has some questions about
its functionality running on 4.0. Any assistance here is certainly appreciated.
Thanks.
Pat Bryant
Software Partners Engineering
----------------------------------------------
We have a product running on Digital Unix that requires 32-bit pointer support.
It already works on V3.2, but we are upgrading to a new Digital Unix release.
In doing so, it is necessary for us to run our own (slightly modified) version
of xtaso_header_edit as described in the Programmer's Guide, Appendix A.
When I attempted to run this, it worked OK, but didn't modify all of the
requisit header files. If you examine the script closely, you'll note it
processes the directory trees /usr/include and /sys/include, but doesn't
follow symbolic links. Unfortunately, in going from V3.2 to V4.0 of Digital
Unix, /sys/include has become a symbolic link to /usr/sys/include, so the header
files in that directory don't get modified by xtaso_header_edit.
My questions:
1. Am I reading the manual incorrectly?
2. I can modify our version of xtaso_header_edit to handle both
versions of Digital Unix, but need to know whether /usr/include
and /usr/sys/include are sufficient on V4.0 or whether I should
also point it at some other directory?
T.R | Title | User | Personal Name | Date | Lines |
---|
9281.1 | | DECCXL::MARIO | | Tue Mar 25 1997 12:43 | 19 |
| The xtaso_header_edit script from the Programmer's guide was never really
a good solution to protect your system's header files. And if it did work,
it caused havoc with installupdate.
As a result, we've implemented a much cleaner solution in PTmin (V4.0D)
for protecting 64-bit system header files when xtaso is used. This
requires upgrading to the version of DECC that will ship with PTmin and
enable a new protect_header feature. The PTmin DECC should work fine on
all V4.* releases.
Send mail offline if you're interested.
You're other choice is to have your customer modify his xtaso_header_edit
script to get it working. Protecting everything under the /usr/include
directory tree should be sufficient. If there are special project
header files where a 64-bit interface needs to be maintained, then the
script will need to be run against those directories as well.
Joe
|