Conference bulova::decw_jan-89_to_nov-90

   Yup, it won't work.

   I was able to get around it the time I did something like this by having
all my database-access stuff being callable and using VAX RPC as a server
to separate the DECwindows client from the database access routines.

   Of course, VAX RPC was cancelled, so it looks like you'll have to write
your own client/server stuff.

					-mjg

There is  a  fix  for this sort of problem in V5.2. It requires some special
compiling  on  the  part  of  the  G_FLOAT  portion  of the program, though.
Basically,  we've  added special labels to VAXCRTL which will allow users to
perform G_FLOAT operations from VAXCRTL.

The versions  of  STDIO.H, MATH.H, STDLIB.H, and UNIXLIB.H shipped with V3.0
of   VAX  C  contain  preprocessor  directives  to  redefine  the  names  of
floating-point  type  dependent  functions  to  the  appropriate  new names.
Unfortunately,  because  of  problems  with release dates, we had to add the
hack  that  you  also  have  to add a /define="CC$mixed_float" switch to the
compile command.  That hack will go away with version 4.0 of VAX C.

We are  strongly recommending that everybody producing a product for V5.2 or
later  use  this method. You might want to check if the RDB people are aware
of it. We would like everybody to know about this fix, but it's hard to find
everyone who uses VAXCRTL...

We have  a  kit available which contains the include files and a copy of the
VMS  V5.2 C RTL. The RTL should work on any V5.0 or later system. Contact me
or Beth (also TLE::) Benoit to see about getting a copy.

- Brad

    The next version of the RDML Preprocessor (in field test) no longer
    requires any application to link with VAXCRTLG (or VAXCRTL for that
    matter).  Of course, people who use functions like printf() will still
    need to, but not on account of RDML.  So the long term problem is solved. 
    
    There is a short term workaround for RDML V1.2 (Rdb/VMS V3.0) if you
    don't need G_FLOAT support. It's not documented, but as long as you do
    not access G_FLOATING data in your program, you may link with VAXCRTL.
    You will get a warning message about CC$G_FLOAT or some such symbol not
    being defined, but that is not a problem.  This is due to the fact that
    we compiled the code in RDMLRTL using CC/G_FLOAT (it doesn't use
    G_FLOATING). 
    
    NOTE: ONLY DO THIS IF YOU ARE POSITIVE THAT YOUR APPLICATION DOES
    NOT READ OR WRITE G_FLOATING DATA.  IF YOU DO IT YOU CAN END UP
    WITH GARBAGE FOR G_FLOATING DATA IN THE DATABASE.
    
    Hope this helps,
    
    Britt...

    Hi,
       I've got a customer with a very similar problem to this, or so
    it appears. The customer works for Oracle, and he is attempting
    to link a C program he has written with DECWINDOWS and Oracle.
    
    The Oracle is linked against the V5 CRTL, not CRTLG, however, he
    still gets errors about multiply defined symbols. Oracle is also
    a shared image.
    
    He's also tried linking Oracle against DECWINDOWS and then the program
    against this. This failed too; I think this is because of the base
    addresses are out ? 
    
    Is there a way round this ?
    
    Thanks in advance...
    
    
    Samantha Holloway, UK SSD, Basingstoke.

If nothing that he's using is compiled /GFLOAT, then it isn't the same problem.
The link maps the ORACLE shareable image and the link that failed should enable
you to figure out why there are MULDEF errors occurring.  Either two modules
(or shareable images) present in the link define the same global names, or
something is causing the same module to get included in the link twice.

ORACLE has had a multitude of problems with the Linker and Image Activator in
the past due to their use of based shareable images.  It's possible that that
is messing things up (yet again).

--PSW

Not really knowing anything about this, but might they be linking against the
CRTL object library rather than the sharable image?  I suspect this could cause
a problem.

Burns

I recently answered an SPR on this exact issue.

The problem  is  that ORACLE shipped a hacked version of the V4.7(?) VAXCRTL
(which  probably  contains  a bug fix they couldn't wait for) under the name
ORACRTL, and made all of the symbols universal in (I believe) ORACLE1.EXE...
They probably mention somewhere that you shouldn't link against VAXCRTL.EXE.
There  is no way to get this crap to work with DECWINDOWS. The only solution
is to get ORACLE to send you a version linked against VAXCRTL, which doesn't
export the names.

- Brad

    Thanks for the replies. I have some more information which may be
    useful(!)
    
    The customer says that Oracle is shipped as a series of object modules
    and libraries. At link time, the user specifies which CTRL he wants
    Oracle to be linked against. The customer is specifying the VAXCRTL
    explicitly not ORACRTL. ( He has also used the DECW image, to no
    avail)
    
    It seems odd that there is a choice between the VAXCRTL and ORACRTL.
    I suppose the question how will the 'universal symbols' effect DECW?
    Does linking against VAXCRTL imply that the symbols will automatically
    be compatible with DECW, or could Oracle be interfering further?
    
    The customer has a 'workaround', he links DECW against some sort
    of 'two_tasks' image which runs the Oracle image for him, however
    he still would like to know whats happening!
    
    
    Thanks,
    
    Samantha.		

Re .8:

What I  was  trying to say is that it's your cutomer linking against VAXCRTL
that  is  the problem. Oracle already links against ORACRTL (which is an old
version  of  VAXCRTL),  then  exports the names. When the user links against
VAXCRTL,  the  names  become  multiply defined, and you see the problems you
mentioned.  There  is  no  way  around  this  problem  using that version of
Oracle's software other than the "two process" approach you mentioned, which
works because neither part of the program will then link against both Oracle
and the C RTL.

- Brad

    Hi there,
    
    Re: .8
    
    Better late than never, the customer definitely does not link against
    ORACRTL (the Oracle shareable library is built during the installation,
    and the installation procedure allows you to select whether you
    want to use the vanilla VAXCRTL or Oracle's munged flavour). 
    
    I'm now working on this problem, and it looks like they're seeing
    the problem because the Oracle shareable library is built as a based
    image.
    
    Graham