lnk2019 unresolved external - not finding own project stuff

[scrognoid]

I am getting unresolved externals for subroutines in the project. The FFT routines below are in fft_tools and the CP* ones are in cpanels2. (DFSD* are in HDF libraries, which is a different matter, and not my question here.) It does this under Debug, but not Release. I'm Defaulting all the name mangling switches - learned my lesson there.


1>------ Rebuild All started: Project: cross2, Configuration: Debug Win32 ------
1>Deleting intermediate files and output files for project 'cross2', configuration 'Debug|Win32'.
1>Compiling with Intel Fortran 11.0.066 [IA-32]...
1>envelope.f90
1>openfft2.f90
1>moy2day.f90
1>slash.f90
1>crossavg.f90
1>mumap.f90
1>hdf_write.f90
1>cross.f90
1>E:\TimDocs\fort\cross\source\cross.f90(304): remark #7000: Two-digit year return value may cause problems with the year 2000. Use DATE_AND_TIME instead [IDATE]
1> call idate(kdat(1),kdat(2),kdat(3))
1>-----------^
1>runtime.f90
1>cpanels2.f90
1>mtape.f90
1>nfcalc.f90
1>hanning.f90
1>lname64.f90
1>scot1.f90
1>fft_tools.f90
1>mulaw.f90
1>hdf4interface.f90
1>Linking...
1>envelope.obj : error LNK2019: unresolved external symbol _CFFT1D referenced in function _ENVELOPE
1>envelope.obj : error LNK2019: unresolved external symbol _SCFFT1D referenced in function _ENVELOPE
1>crossavg.obj : error LNK2001: unresolved external symbol _SCFFT1D
1>crossavg.obj : error LNK2019: unresolved external symbol _CSFFT1D referenced in function _CROSSAVG
1>hdf_write.obj : error LNK2019: unresolved external symbol _DFSDSETDIMS referenced in function _HDF_WRITE
1>hdf_write.obj : error LNK2019: unresolved external symbol _DFSDSETDATASTRS referenced in function _HDF_WRITE
1>hdf_write.obj : error LNK2019: unresolved external symbol _DFSDSETDIMSTRS referenced in function _HDF_WRITE
1>hdf_write.obj : error LNK2019: unresolved external symbol _DFSDSETDIMSCALE referenced in function _HDF_WRITE
1>hdf_write.obj : error LNK2019: unresolved external symbol _DFSDPUTDATA referenced in function _HDF_WRITE
1>hanning.obj : error LNK2019: unresolved external symbol _CPINIT referenced in function _HANNING
1>hanning.obj : error LNK2019: unresolved external symbol _CPSHOW referenced in function _HANNING
1>libifcoremt.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main
1>Debug\cross2.exe : fatal error LNK1120: 11 unresolved externals
1>
1>Build log written to "file://E:\TimDocs\fort\cross\cross2\Debug\BuildLog.htm"
1>cross2 - 13 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

[Steven_L_Intel1]

Attaching the buildlog.htm from the Debug folder would be more instructive as it will show exactly what is happening with each step. Do you perhaps have directives in the CP and FFT routines that would change their names (or STDCALL)? I also note the reference to _MAIN__ - it sounds as if you don't have a Fortran main program in this build.

[scrognoid]

Calling Convention and Name Case Interpretation are set to Default. The Main program is cross.f90. I'm attaching the whole solution as .zip. The build log is included.

[Steven_L_Intel1]

Nothing obvious there. Try this. Open a Fortran Build Environment command prompt window. Set default (CD) to the Debug folder of the project after a build fails. Type the command:

dumpbin -symbols openfft2.obj > openfft2.txt

Open the .txt in NOTEPAD and search for CFFT1D. What does it find? Attach the .txt. Do the same for cross.obj.

[scrognoid]

I assume I'm looking for lines like this:

01A 00001ABE SECT2 notype () External | _CPINT

cpanels2.f90, for example contains several subroutines and I find entries like this for most, but not all.

Does it have something to do with Disable Specific Diagnostics? The missing routines come from files sharing that option.

Files attached.

[Steven_L_Intel1]

Yes - it looks as if the compiler simply did not compile those sources. What are the specific diagnostics you told it to disable? I don't have a ready way of looking them up by number.

[scrognoid]

I had to do a few:

In cpanels2.f90, I'm passing a stored address with %val, that is interepretted as real, double, etc.:

E:TimDocsfortcrosssourcecpanels2.f90(173): error #6633: The type of the actual argument differs from the type of the dummy argument.   [%%VAL]
            call rset(%val(cp_addr(i)),rtmp)
-----------------------^
E:TimDocsfortcrosssourcecpanels2.f90(177): error #6633: The type of the actual argument differs from the type of the dummy argument.   [%%VAL]
            call dset(%val(cp_addr(i)),dtmp)
-----------------------^
E:TimDocsfortcrosssourcecpanels2.f90(183): error #6633: The type of the actual argument differs from the type of the dummy argument.   [%%VAL]
            call cset(%val(cp_addr(i)),ctmp,lctmp)
-----------------------^
E:TimDocsfortcrosssourcecpanels2.f90(187): error #6633: The type of the actual argument differs from the type of the dummy argument.   [%%VAL]
            call lset(%val(cp_addr(i)),qtmp)
-----------------------^
compilation aborted for E:TimDocsfortcrosssourcecpanels2.f90 (code 1)

This error makes no sense to me. I'm passing a litteral string that is shorter than the character variable receiving it:

E:TimDocsfortcrosssourcecross.f90(497): error #7938: Character length argument mismatch.   ['_cgimg']
         call hdf_write(outroot,lout,'_cgimg',6,dbhdf,saxis,tauax, &

Those are the two types involved. The FFT routines have type mismatches also because of tricks that can be played with forward and reverse FFTs. (Legacy code.)

[Steven_L_Intel1]

Ah, I see. If you disable an error-level diagnostic, all that means is that you don't see the error, but the error is still there and the source won't compile. Disabling error-level diagnostics makes little sense to me.

I suggest that instead you disable Generate Interface Blocks and Check Routine Interfaces - this will prevent the compiler for checking for these errors. Perhaps there is another way to solve the problem you're using %VAL to get around.

[scrognoid]

That seems to be working. Thanks.

Yes, allowing the user to hide a fatal error message makes little sense. The documentation could be clearer here. Disable Specific Diagnostics, Check Routine Interfaces, Generate Interface Blocks are all together on the Diagnostics Tab and are all part of the /warn flag. How's a poor user to know the difference?

[Steven_L_Intel1]

Well, they're not all part of /warn - only Check Routine Interfaces is. They are all on the Diagnostics tab.

I am going to suggest to the development team that supporessing error-level diagnostics makes no sense. On a semi-related note, a future compiler version won't require Generate Interface Blocks to be separately set as long as you have Check Routine Interfaces enabled.

[Steven_L_Intel1]

In a future update, if you have asked to disable an E or F-level diagnostic and that diagnostic would be issued, it will be issued anyway along with a message saying that it cannot be disabled. I had suggested to the developer that this second message say "I'm sorry, Dave, I'm afraid I can't do that", but she didn't accept it.

BTW, the reason behind this is that the C++ compiler does have the ability to have "soft" errors and the compilation continues, though I'm uncertain of what you get at the end. Fortran doesn't do that and the resulting object is empty if E or F-level errors are detected. When the ability to disable individual diagnostics was added (great for warnings), this distinction was missed.

[Steven_L_Intel1]

This issue was resolved in Update 2 - the compiler now complains if you try to suppress an error diagnostic.