topic Re: link problem in Operating System - OpenVMS

link problem

zhilin fan — Tue, 06 Feb 2007 20:15:51 GMT

My sample Fortran application call C Run Time Library Qsort function.
linked in alpha openVMS 7.3-2 is ok.
=====================================================
$fort qsort_sample.for
$link qsort_sample,sys$library:vaxcrtl.olb/lib

but since I64 does not have VAXCRTL.OLB , I use imagelib.olb instead
to link in OpenVMS Integrity Servers (I64) 8.2
but I got undefined symbol error:
=====================================================
$ fort qsort_sample.for
$ link qsort_example ,sys$library:imagelib.olb/lib
%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-I-UDFSYM, QSORT
%ILINK-W-USEUNDEF, undefined symbol QSORT referenced
section: $CODE$
offset: %X0000000000000080 slot: 2
module: QSORT_EXAMPLE
file: USER2:[ZFAN]QSORT_EXAMPLE.OBJ

Anyone have a idea ?

Zhilin Fan

Re: link problem

Steven Schweda — Tue, 06 Feb 2007 20:47:42 GMT

alp $ type qs0.for
program qs
call qsort()
end
alp $ for qs0
alp $ link qs0
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, QSORT
%LINK-W-USEUNDEF, undefined symbol QSORT referenced
in psect $LINK$ offset %X00000040
in module QS file ALP$DKA0:[SMS]QS0.OBJ;1

alp $ type qs1.for
program qs
call decc$qsort()
end
alp $ for qs1
alp $ link qs1 !!! No special stuff needed.
alp $

Functions in the DEC C libraries have a
"DECC$" prefix (or worse).

alp $ for /vers
HP Fortran V7.6-3276-48D52

alp $ tcpip show vers !!! Easy path to details.

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2

Re: link problem

Hoff — Tue, 06 Feb 2007 21:16:47 GMT

Some background on C on OpenVMS...

VAXCRTL.OLB is an ancient and (mostly) long-forgotten technique for including object code modules for VAX C code. The replacement for VAX C is VAXCRTL.EXE, a shareable image. This too has been replaced back in 1993; the VAX C V3.2 compiler was superceded by the ANSI C DEC C V4.0 compiler in 1993.

DEC C for OpenVMS VAX does not use and does not need the VAXCRTL modules, object library or shareable image.

DEC C is massively better at finding latent bugs in C code, and more recent compilers are best at this. VAX C is about the definition of laissez faire compilation. DEC C finds and reports all manner of latent coding bugs.

The default link path includes IMAGELIB.OLB, a shareable image library, and this is automatically including in the path of the linker. Unless you have told the linker to exclude it, it's always present.

Directly accessing routines in the C library from languages other than C has been a bit iffy. HP likely wants you to use a C wrapper around the function, and that would pick up the prefix automatically. (The addition of the decc$ prefix is why the the DEC C shareable can be in IMAGELIB, and IMAGELIB is in the default path. VAX C didn't prefix routines, and that meant that C functions could be included erroneously should VAXCRTL.EXE have been included in the default path; inserted into IMAGELIB. Because of this, VAXCRTL could not be in IMAGELIB.OLB.)

With some C functions, there is also a sensitivity around the initialization of the RTL. There's a routine in the C library that can get called to resolve this. C main functions get this for free, as part of what the C compiler inserts for the main() function.

Re: link problem

John Gillings — Wed, 07 Feb 2007 20:27:51 GMT

The "right" way to do this would be to write a C routine which calls qsort, that you can call from your Fortran program. That way you have control over parameter passing between Fortran and C, and the RTL issues mentioned by Hoff are dealt with by the compilers.

Steven's suggestion will probably work for qsort, but might not for other RTL routines, or into the future.

Re: link problem

Steven Schweda — Wed, 07 Feb 2007 22:46:30 GMT

> Steven's suggestion will probably work for
> qsort, but [...]

For the record, my only claim is that I
solved LINK problem. I did not look at the
attachment, and I have no idea if the qsort()
arguments are being passed correctly from the
Fortran (or, as I like to remember it,
FORTRAN) code. (My examples didn't pass any
arguments, as you may have noticed.)

And "into the future", I would not expect any
major changes to this part of
DEC/Compaq/HP/(whatever) C (other than its
name), but it may be that after 14 years with
no such changes, the time has come (or will
come before we're all dead). I won't hold my
breath.