Warning; things not the same in 8.1

[Intel_C_Intel]

Recompiling an existing production product with 8.1 failed with the follwoing unresolved symbols and also refused toallow parameter MAXFI in this context:

& FILES(1:MAXFI)%DDNAME /MAXFI*' '/,&

SYSIO.obj : error LNK2019: unresolved external symbol _BEEPQQ referenced in function _BEEP

SYSIO.obj : error LNK2019: unresolved external symbol _DELFILESQQ referenced in function _DELFILES.L

OSIR.obj : error LNK2001: unresolved external symbol _DELFILESQQ

PSEARCH.obj : error LNK2019: unresolved external symbol _SORTQQ referenced in function _SRCHSET.L

OSIR.obj : error LNK2019: unresolved external symbol _GETDRIVEDIRQQ referenced in function _MAIN__.L

DIALCOM.obj : error LNK2019: unresolved external symbol _GETDRIVEDIRQQ referenced in function _DIALCOM.L

I'm not sure what the .l suffix means, either.

These things worked fine in all releases for the last year.

[Steven_L_Intel1]

There's not enough context here to understand what the problem is. I don't know of any significant change in 8.1 that would be in play here. Please submit a complete example to Premier Support and we'll take a look.

[Intel_C_Intel]

I'll do that eventually, but for context, the first error is a parameter of MAXFI set to the value 20, and the statement is a DATA statement. Error was "invalid int he context.." referring, I think to the first occurrence. All worked fine before. The other errors are simple enough,: can't find subroutines supposed to be in Intel libraies. Worked fine before--no change in my code for 6 months...yes I've got all the use statements in the routines.

For now, it's easier for me to downgrade to 8.0 since I don't need anything in 8.1; just thought it would be nice to use the latest compiler...

Message Edited by nvaneck@comcast.net on 09-14-2004 06:19 AM

[Steven_L_Intel1]

I can't think of any changes that would affect this. Please do send us a problem report and attach a zip of your project. Offhand, I don't know what the .L means either.

[Intel_C_Intel]

I did submit it, but have now found the problem. It is that USE IFPORT is at least insufficient and you must specify Use Portlib library in the Librairies menu under Fortran -Libraries in your project configuration. I don't know if the USE statement is irrelevant, however--you may need both of them. This was not the case in the previous release, at least for my project.

But the problem with the parameter statement still stands......

Message Edited by nvaneck@comcast.net on 09-17-2004 08:22 AM

[Steven_L_Intel1]

I see your problem report. The linking error is due to your specifying /fpscomp:nolibs - no change in 8.1. I'm still looking at the other issue.

[Intel_C_Intel]

Ok, but I didn't specify that; it must have come from not using "Use Portlib Library" under the fortran options sheet as I described above.

So do you think one needs to have both the USE IFPORT in the source AND then "Use Portlib Library" to avoid this problem or is thesource statement USE IFPORT superfluous?

And somthing did change to cause this behavior since I did not touch the project between compiles by the two versions.

Message Edited by nvaneck@comcast.net on 09-17-2004 09:37 AM

Message Edited by nvaneck@comcast.net on 09-17-2004 10:29 AM

[Steven_L_Intel1]

The USE IFPORT is all you should need. I will look further at this on Monday. I can tell you that all your sources built for me without error, so I have no idea what the parameter problem is. The build log you supplied did not show an error.

[Intel_C_Intel]

Thanks for checkingon this , Steve. I can only tell you that it didn't work for me until I added the Use Portlib Library to the fortran options. I assume you tried the release configuration, since the debug version already had that setting--that's how I discoverd the fix.....

[keefer]

Hi,

I have a similar problem. Code that compilied and linked under 8.0 now generates a link error:

Qcell9 error LNK2019: unresolved external symbol _WinMain@16 referenced in function _WinMainCRTStartup

I assume the problem is some setting in the MS IDE. I sent an error report and got the usual response-please send a short version of the code. Well, I don't think its the code, I think the linker is not looking for the right library. Why the one it looked for before doesn't work or why the setting in MS Studio .NET changed I haven't a clue. Why can't the "supporter" at Premier Support just tell me what library I should be looking for. I explained the problem in detail, but I don't think the "supporter" read it or understood it. If one goes to the effort to explain the compiler, editing/building environment, etc., does the report get routed to somebody who knows anything about IVF?

Regards,

Keith

[Steven_L_Intel1]

Keith,

Your problem is not a missing library - it's an incorrect setting for the linker option /subsystem. I can't imagine how this would change between 8.0 and 8.1.

You get this error if you create a project that is of type "Windows Application" but you really have a "Console" type application.

Tell me the case number and I'll look at it on Monday. It would help if you would upload a ZIP of your "solution" directory. If you don't think the support engineer understands your question, simply ask that it be escalated and it will be. Many of the SEs do understand IVF, but not all. We're changing the way we assign cases so that it's more likely you'll get a relevant early response than the way we've done it in the past.

[keefer]

Thanks, Steve,
I knew it wasn't a missing library-sorry if I gave you that impression. I felt quite sure that it was a setting in the "properties page" for the build, under Linker. I sent the whole shebang to my "SE" (="Supporter"?) ("shebang"= *.suo, etc.) I believe that with enough patience and time, I might have figured it out.

FWIW, I had no problem figuring out which file would upgrade my non-Pro, non-64EMT(?) non-Itanium, IA32 compilier. It was confusing at first, but upon carefully reading the descriptions, it was straightforward (even if it didn't build correctly). I think that there is nothing wrong with the WEB page. I think that the nomenclature - e.g. IVF8.x; IVF8.X Pro; IVF8.X EMT64(?); CVF Compatible; for the various platforms should be standardized and communicated. (I found it amusing that Jugoslav, Master of the Windows API, had problems :)

With Sincere Regards,
Keith

[keefer]

Steve,

P.S. The Premier Support Issue numbers are 267102 and 264402

Regards,

Keith

[wkramer]

Hello,

I am having exactly the same problem. After installation of version 8.1, I get unresolved external errors (RAISEQQ, CLEARSTATUSFPQQ etc.) It looks like IVF can no longer find the libraries. The same project used to build correctly with version 8.0. I uploaded the project before to premier support for another problem (issue number 255469got anwered, but te uploaded project is still avaiable. I downloaded it myself to check whether I made any changes I forgot about).

Walter Kramer

[Steven_L_Intel1]

Thanks - we'll take a look. Make sure that the Compatibility..Use PowerStation Portability Library is set to Yes.

[wkramer]

Steve,

I didn't have powerstation portability libraries checked. Checking does solve the problem.

It remains weird though that under version 8.0 I had /fpscomp:nolibs and it functioned OK. So something must have changed between the two versions.

Thanks,

Walter Kramer

[Lorri_M_Intel]

Actually - you're right. Something did change. The driver used to ignore /fpscomp:[no]libs, and that was repaired. I can't recall exactly when that happened, but it could have been between 8.0 and 8.1.

- Lorri

[wkramer]

Thanks that clarifies a lot. Obviously fpscomp:[no]libs was already ignored under CVF. I never had fps compatibilty libraries checked.

Walter Kramer

[Steven_L_Intel1]

The default is to have the box checked, but I can see how it may have been turned off unintentionally in the past.