linking on X86 : %ILINK-W-DRELOSYM, debug relocation for undefined symbol

[joukj]

After upgrading today to the latest C and Fortran compilers on OpenVMS x86_64 V9.2-1, I get while linking a C/F90 project a lot of the following warnings. I did not get them with the previous compilers

Code: Select all

[......]
%ILINK-W-DRELOSYM, debug relocation for undefined symbol
        relocation type: 64
        to section: .debug_info
        offset: %X000000000000075B
        undefined symbol: pthread_exc_noexcmem_e
        module: WX_INPUT_HANDLER
        file: $DISK16:[JOUKJ.plot]pltlib.olb;37
%ILINK-W-DRELOSYM, debug relocation for undefined symbol
        relocation type: 64
        to section: .debug_info
        offset: %X000000000000015D
        undefined symbol: TERM_NAME
        module: REPLY_OPER9
        file: $DISK16:[JOUKJ.rtl]rtllib.OLB;14
%ILINK-I-THREADUPCALLS, user thread upcalls automatically enabled
%MMS-F-ABORT, For target jj$rtl.exe, CLI returned abort status: %X1789A0C0.
%MMS-F-ABORT, For target all, CLI returned abort status: %X10EE8034.
%MMS-F-ABORT, For target jj_rtl, CLI returned abort status: %X10EE8034.
%MMS-F-ABORT, For target top, CLI returned abort status: %X10EE8034.
  

What is it telling me and how can I suppress these warnings. They are a nuisance since MMS (without /ignore) stops e make-cascade..


regards
Jouk

[jreagan]

Yes, we've seen the same thing when trying to build the Fortran compiler itself with the newer C compiler. We "improved" some of the debug generation but then it got confused with external routine definitions that were removed (but the associated debug information was not). Perhaps LINK/NODEBUG might help? I believe we fixed this in the last few days but it was after we created the kits that just went live.

[joukj]

LINK/NODEBUG give the same warnings

[jreagan]

Can you try LINK/NOTRACEBACK and see if it helps?

[joukj]

LINK/NOTRACEBACK does not give the ": %ILINK-W-DRELOSYM, debug relocation for undefined symbol" mesages
but still the %ILINK-I-UDFSYM messages on the same "externals" are still present (they were also there in my original report, but I did not list them)


And the stange thing is that also some of the missing symbols are (I compile with /name=lower) are some local variables capitlized.

[craigberry]

I'm also getting undefined symbols building Perl with the updated C compiler:

Code: Select all

$ Link /NoTrace/NoMap/NoDebug/NoFull/NoCross/Exe=Sys$Disk:[]miniperl.exe miniperlmain.obj,libperlmini.olb/Library ,[]crtl.opt/Options
%ILINK-W-NUDFSYMS, 5 undefined symbols:
%ILINK-I-UDFSYM, 	DECC$$GL___CRTL_VER_BUILD
%ILINK-I-UDFSYM, 	IN6ADDR_ANY
%ILINK-I-UDFSYM, 	IN6ADDR_LOOPBACK
%ILINK-I-UDFSYM, 	_NS_FLAGDATA
%ILINK-I-UDFSYM, 	_RES

As I said on c.o.v yesterday:

>
> C$_QSORT2BIG is declared in errnodef.h, DECC$$GL___CRTL_VER_BUILD in
> unixlib.h, in6addr_any and in6addr_loopback in in6.h, _ns_flagdata in
> nameser.h, and _res is in resolv.h.
>
> So there is some kind of gear slippage among the compiler, the headers,
> and the library. As far as I can see, the only thing new this week is
> the compiler.

Upgrading from TCPIP X6.0-22 to TCPIP V6.0-23 did not make any
difference. I thought it might since some of the missing symbols are
TCP/IP-related.


Linking /NOTRACE/NODEBUG made it able to find C$_QSORT2BIG, but not the others.

Added in 1 hour 16 minutes 44 seconds:
Hmm. Compiling /NOOPT makes all the undefined symbol warnings go away.