Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
scrognoid
Total Points:
440
Status Points:
390
Green Belt
March 27, 2009 7:31 AM PDT
lnk2019 unresolved external - not finding own project stuff
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(R) 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 ==========
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
March 27, 2009 8:10 AM PDT
Rate
 
#1
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
Total Points:
440
Status Points:
390
Green Belt
March 27, 2009 11:00 AM PDT
Rate
 
#2 Reply to #1
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.


 Attachments 
cross2.zip
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
March 27, 2009 12:20 PM PDT
Rate
 
#3 Reply to #2
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
Total Points:
440
Status Points:
390
Green Belt
March 27, 2009 2:36 PM PDT
Rate
 
#4 Reply to #3
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.



 Attachments 
dumbin1.zip
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
March 27, 2009 3:13 PM PDT
Rate
 
#5 Reply to #4
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
Total Points:
440
Status Points:
390
Green Belt
March 27, 2009 3:35 PM PDT
Rate
 
#6 Reply to #5
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:\TimDocs\fort\cross\source\cpanels2.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:\TimDocs\fort\cross\source\cpanels2.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:\TimDocs\fort\cross\source\cpanels2.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:\TimDocs\fort\cross\source\cpanels2.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:\TimDocs\fort\cross\source\cpanels2.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:\TimDocs\fort\cross\source\cross.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.)
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
March 28, 2009 4:58 AM PDT
Rate
 
#7 Reply to #6
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
Total Points:
440
Status Points:
390
Green Belt
March 30, 2009 12:25 PM PDT
Rate
 
#8 Reply to #7
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?
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
March 30, 2009 1:00 PM PDT
Rate
 
#9 Reply to #8
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.
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
June 1, 2009 3:35 PM PDT
Rate
 
#10
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.
Steve Lionel (Intel)
Total Points:
115,145
Status Points:
115,145
Black Belt
November 9, 2009 10:47 AM PST
Rate
 
#11 Reply to #10
This issue was resolved in Update 2 - the compiler now complains if you try to suppress an error diagnostic.


Intel Software Network Forums Statistics

8487 users have contributed to 31622 threads and 100698 posts to date.
In the past 24 hours, we have 35 new thread(s) 121 new posts(s), and 186 new user(s).

In the past 3 days, the most popular thread for everyone has been gemm(A,A,A) like possible? The most posts were made to gemm(A,A,A) like possible? The post with the most views is Dear Steve, excuse me for a d

Please welcome our newest member chat1983