Linker problems with C++ subroutines

Linker problems with C++ subroutines

Post by <w.. » Thu, 31 Oct 1996 04:00:00



Hello,

a user with a pascal main program and some C++ subroutines reported me the
following problem:

        Environment:
        OpenVMS 6.1 VAX, Pascal 5.1-22, C++ 5.0

        Problem:
        If C++ subroutines (stored in a library) call any SIR library routine
        (LIB$..., MTH$..., etc) the linker displays an undefined symbol message.
        If the C++ subroutine is specified as parameter in the link command, it
        works without any error message. In case of the user have a lot of such
        subroutines the length of the commandline goes out of order.

Any solution or help is welcome.

TIA R. Wingert

 
 
 

Linker problems with C++ subroutines

Post by Robert Koehl » Thu, 31 Oct 1996 04:00:00


:       Environment:
:       OpenVMS 6.1 VAX, Pascal 5.1-22, C++ 5.0
:      
:       Problem:
:       If C++ subroutines (stored in a library) call any SIR library routine
:       (LIB$..., MTH$..., etc) the linker displays an undefined symbol message.
:       If the C++ subroutine is specified as parameter in the link command, it
:       works without any error message. In case of the user have a lot of such
:       subroutines the length of the commandline goes out of order.

I see two problems: inability to reference LIB$ et. al, and command lines
that are too long.

The exact content error message would help, but since you didn't provide it,
I'll guess out loud:

As far as LIB$ and such, treat these as non-C++ language routines by using
extern "C" when they are prototyped, or simply use the headers (such as
lib$routines.h) which do so for you.

LINKing many routines can be done via an options file (.opt), on which each
line can list one or more object files, multiple lines can be used until all
object files have been listed.  Another fix is to put all the objects
into an object libary and only reference the main routine and object library
in the LINK command.  Using an object library can have performance benefits if
you have to LINK many times but are only recompiling a few of the routines.

------------------------------------------------------------------------------
Bob Koehler                     | CSC/SSD/MITG


 
 
 

1. Linker problems with C++ subroutines

Hello,

Thanks to Bob Koehler for the workaround, but I would like to understand what's
wrong? If we compile the C++ modules with the DEC C compiler, we can link all
together (libraries, and other objectes) without any undefined symbol error.
Also if we don't have any C++ object we have build application with libraries.
Within all C++ modules the application programer has used the external C
statement without any effect to the linker problem.

What is different to have C++ objects or not. Only if we have C++ objects and
library routines of other languages, which call LIB$..., MTH$... or any other
library of system, we get the undefined symbol error message. Then we have to
extract this objects and to specify them as linker parameter. We have now a
selffound workaround: extract all objects into one objectfile. But why have
we to do this. I think this is not a normal system behaviour, or is it?

TIA, R. Wingert

2. Netscape Never Checks for Mail

3. Linker problems with C++ subroutines (correction of description)

4. Word 2000 inserting graphics

5. C++ V6.5 linker performance optimization?

6. Help with access lists for firewall

7. C++ compiler and linker warnings

8. DCL subroutine definition problem

9. Problem using Linker Option SYMBOL=

10. DEC C linker problem

11. Linker Problem

12. Re(2): Linker Problems with Alpha VMS Version 6.2