| In general moving back and forth between v3.2c and v4.0b should not
be a problem. Donna tells me the reason he's not seeing the device
at v4.0b bootup time is that he hasn't updated the kernal configuration
file. If this is done, and the kernel is rebuilt, then there shouldn't
be a problem. Otherwise, it's OK to do a MAKEDEV now so he can
specify the special device file.
The reason he's probably not getting the best capacity/performance
of the DLT4000 is that he's specifying the incorrect special device
file. He can check out man pages on tz to figure out which device
file does the needed compression.
He's squared away and I'm going to close this.
Gerrit
|
| More questions:
1) In his compilation he's not getting any link errors
on a fork() call. Is something like this implemented in
VMS now, or does he need to recode a different method.
2) His app uses named ports referenced through /etc/services
is there a way to get a named port in VMS?
3) Why are you handling all the VMS questions if it
isn't something you have experience in? And [seriously
folks], "is there a way to pull yourself out of the loop
since you're not a VMS person; I know I had contact with
some other people with VMS knowledge, Chuck Newman for
instance."
Gerrit
|
| From: David Partridge <[email protected]>
To: alpha-developer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Garrit: Call # 3621
Date: Thu, 15 May 1997 17:29:30 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hello Garrit,
Here is the set of errors I see when I start up the debugger:
%DEBUG-E-INTERR, debugger error in DBG_RST_FROM_DST: could not find
corresponding RST or session corruption
%DEBUG-I-INITIAL, Language: C_PLUS_PLUS, Module: TEST
%DEBUG-I-NOTATMAIN, Type GO to reach MAIN program
%DEBUG-W-SRCNOSRCLIN, No source line for address: 0000000000030000
When I type Go, I get
%DEBUG-W-SRCNOSRCLIN, No source line for address: 00000000000320EC
break at routine MAIN
-----------------------------
Every file has been compiled with the command:
cxx/nolist/noopt/debug test.cxx
Then placed into a library with the command:
library/replace mylib.a test.obj
Then linked with the command:
link/debug/exe=bindir:test.exe/nomap -
libdir:mylib.a/lib/include=test.exe, -
libdir:mylib1.a/lib, -
uxcrtl/opt
where the file uxcrtl.opt has the line:
sys$share:ucx$rpcxdr_shr/share
I've tried to use the SET SOURCE command to set the source path to the
correct
directories, but this has no effect. SHOW SOURCE shows that the path is
correct, but it still won't load the source files.
I have another executable that has a C front end. When I run this in
the
debugger, the C code is visible, but as soon as I step into a C++ file,
I cannot see the source.
-----------------------------
One other issue that arises has to do with the fact that we overload the
new operator in C++ in order to make it call calloc, and thus provide us
with memory that has been zeroed. Simply overloading the generic new
operator does not seem to work (it does on all Unix systems that we have
tried and on NT), so we have defined our own versions of __nw__FUi and
__dl__FPv. This seems to work correctly, but means that we always get
link warnings of the form:
%LINK-W-MULDEF, symbol DECC$__DL__XPV multiply defined
in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
%LINK-W-MULDEF, symbol DECC$__NW__XUI multiply defined
in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
This doesn't seem to cause any problem, but we would prefer not to have
the warnings. Is there a better method that we could use to ensure that
new returns zeroed memory?
------------------------------
And finally, the end product that we ship consists of a number of c++
executables, a large library of C++ objects, and some c stubs. The
customer implements the C stubs, links with the C++ library we provide
and creates an executable that they redistribute to their customers. We
require our customer to have C, but we do not want to require them to
have
C++, and their end customers shouldn't need either. Is there a library
or a set of objects that we can incorporate into our library, that we
can redistribute to our customer so that they can link with our C++
library
without requiring any of the C++ runtime on their system? Also, do we
need to specify any special options when linking our C++ executables so
that they will use a static runtime and run on systems where C++ is not
installed.
Thank you for your help.
Dave Partridge
Dharma Systems, Inc
(603) 886-1400 x12
[email protected]
|