05-10-2013 05:24 AM
In the course of "porting" an application from the Alpha to the Itanium platform, I ran into an odd error message:
HP zx6000 (1.50GHz/6.0MB) running OpenVMS V8.4
HP Fortran V8.2-104939
The source FORTRAN file contained many modules 1 of which has a warning about a variable being used before it is defined (I'll fix that later as it is in a module that is not currently used.) The linker reports compiler warnings for 5 modules rather than 1. It seems, that once a compiler warning is encountered, any module "linked" after that is also flagged as having warnings even when they do not. There are 4 subroutines/functions in the suource file after the one with the error.
Since this application is a home grown one (my use only), I am using the hobbyist license and thus do not have a way to officially report this. Can someone that has a contract forward this along? This is new to Itanium as this is not a problem on the Alpha.
05-10-2013 05:51 AM
Warning messages in the Linker are more important than you realize. Because of the library and the options etc you can use in the linking statement errors will cascade... for example
%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-W-USEUNDEF, undefined symbol SCSLOGERR referenced
offset: %X0000000000002C90 slot: 0
$ LINK/NOMAP/EXE=WMS$$EXE_SCS:PURGE_QUE SCSLIB_AXP/INCLUDE=PURGE_QUE$MAIN,-
WCH_VWRTOM> help/message NUDFSYMS
NUDFSYMS, 'number' undefined symbols:
Facility: LINK, Linker Utility
Explanation: The linker found undefined symbols at the end of Pass 1.
User Action: Ensure that all referenced symbols are defined.
NUDFSYMS, 'number' undefined symbols:
Facility: ILINK, OpenVMS I64 Linker Utility
Explanation: The number reported is the number of references found that
User Action: None.
Make sure your object files are compiled cleanly and in the libraries they are being linked from to clear the problem.
05-10-2013 06:10 AM
Please realize that this can be avoided by fixing the offending module. I get that. The problem I am trying to report is the LINKER reporting warnings where there are none (in the subsequent modules).
05-10-2013 06:16 AM
The OP talks about compiler warnings, which the linker reports (and incorporates into images).
That was always the case on Alpha and Itanium.
05-10-2013 06:28 AM
$link x/share=y sys$input/opt
I will work on a small reproducer as I am restricted on the distribution of hte actual code.
05-10-2013 07:18 AM
The compiler warning belongs to the end of module information. On Alpha this is in the EEOM record, on Itanium it is in the ELF header. So the linker should report the warning per module, not per function/subroutine.
On Itanium you may want to do an $ pipe analyze/obj/header of_the_object_file |search sys$pipe "Completion Code:",flags. It is quite posible, but I can't check from here, that the FORTRAN compiler generates multiple object modules and puts them into one object file. The above command would then show more than two output lines. (How many elements, that is object modules are in the OLB?)
05-11-2013 03:39 PM
Anyway, using the PIPE as described before indicates that the singular .OBJ file contains multiple object modules. I got over 100 lines from the command.
I also noticed that the Librarian displayed the same issue. So this in fact may be a problem with the object module creation not the linker or librarian. I noticed that the "warning" flag was set in all of the modules after the one thta actually had the warning.
At this point, I would think that this should be escalated to the compiler group. I will test this with another language sometime to see if this is a common issue.
Thanks for the assistance,
05-13-2013 12:54 AM
>>> At this point, I would think that this should be escalated to the compiler group. I will test this with another language sometime to see if this is a common issue.
For a number of reasons, I didn't really expect that the linker had a problem. Also, I don't know which other compilers besides BLISS can create multiple object modules from a single source file. For BLISS however you have to explicitly specify different modules in the source. Then BLISS generated object modules show the same problem. So it looks like a "common issue". (For almost all compilers, you can compile many sources into one object module, but that is quite the opposite of what FORTRAN is doing here.)
You probably fixed the problem in the source code, which caused the warning. If applicable, the other options are to split the source after function A or to move function A to the end of the single source.
05-15-2013 06:57 PM
Fortran generates multiple modules per object file (ie, each subroutine turns into a separate module). BLISS can do it, but that isn't the normal coding style. I think you can get COBOL to do it also.