Help! unresolved externals _errno and __pxcptinfoptrs

[isn-removed200637]

I am using CVF version 6.6.0.
I have just had to make some small Fortran changes
(changing CHARACTER variable lengths for storing
filename+path) to an older project created with an
earlier version and the link
fails because the library search fails to satisfy all
external references. The routines I need to know the
locations of are listed in thediagnostics below

Linking...
dfor.lib(for_m_qqs.obj) : error LNK2001: unresolved external symbol _errno
dfor.lib(for_m_diskdir.obj) : error LNK2001: unresolved external symbol _errno
dfor.lib(for_portlib.obj) : error LNK2001: unresolved external symbol _errno
dfor.lib(for_init.obj) : error LNK2001: unresolved external symbol __pxcptinfoptrs
Release/wireframe.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.

The project has multithreaded libraries selected and
the project settings include the following libraries
to be searched:

kernel32.lib libcmt.lib dfqwin.lib DFQW_MDI.LIB COMDLG32.LIB

I choose to ignore DFCONSOL.LIB and LIBC.LIB because I get
loads of duplicate references otherwise during the linker step.
Can anyone direct me to the library that contains the missing objects?
TIA

[Steven_L_Intel1]

You have the dreaded MCLS (Multiple C Library Syndrome). Your excluding libc and dfconsol makes the problem worse, which is that you've got sources compiled with incompatible library settings. See The Heartbreak of MCLS (the sequel) for the cure.

Steve

[isn-removed200637]

Thanks Steve, I will look there..in the meantime I
found DFORMT.LIB in ../DF98/LIB/ and added it to the project library search list and the program linked ok.
I used DUMPBIN /archivemembers /out:dformt.lis on it but could not find members with the names of the missing .OBJs in the resulting listing!
The question is, have the 'correct' library members been added to the .EXE file as a result?

[Steven_L_Intel1]

I don't know what you mean by "library members added to the .EXE". If the program is using QuickWin (as the reference to DFQWIN.LIB suggests), then it requires the multithreaded libraries (DFORMT.LIB and LIBCMT.LIB). This should happen automatically if you specify the libraries settings properly in Developer Studio, or use /libs:qwin from the command line.

Steve

[isn-removed200637]

Sorry, but what I mean is this: while the compiler is
creating the code in the .OBJ files corresponding to each .F90 or .FOR file that is included in a project, there is list of unsatisfied external references (e.g. calls to routines or references to functions e.g. WINMAIN, MAIN, TAN, SIN, EXP, RANDOM, whatever) that must be satisfied by the linker before the .EXE file (or DLL) can be built.
The libraries are where these reside. These libraries appear to contain .OBJ files which themselves may contain several of the
required entry points to functions or routines that are need by the program (and by functions referenced by the program, and by functions/routines referenced by routines referenced by other routines, ad infinitum).
Now it would appear that SOME of the .OBJ files in different .LIB library modules contain entry points having the same name (apparent duplicates), but which may be to DIFFERENT code, because of the way that or function for which the libraries are created.
So, depending on what libraries are included in the search, and even on the order, might it not be possible to satify all the required references but have DIFFERENT code in different projects for the SAME reference?
In which case, is it possible to have the 'wrong' or incompatible code because of the library selection or search order?
In my case, because I had to add a specific reference to DFORMT.LIB in the library search list to get the linker to complete linking OK, it would appear that DFORMT.LIB was not AUTOMATICALLY being searched even though the project was marked as requiring multithreaded libraries.
Finally and BTW, is there a primer on how to interpret all the names that appear in the .MAP file created by the compiler/linker?

[Steven_L_Intel1]

When the files are compiled, the compiler inserts invisible directives in the object file (OBJCOMMENTs) that tell the linker what libraries to search first. The choice of libraries depends on the Libraries setting when compiling. If you compile some files with one setting, and other files with another, you can get conflicting libraries (for example, DFQWIN and DFCONSOL are mutually exclusive).

It's not the search order - or at least it shouldn't be.

I don't understand your MAP question.

Steve