Project Settings

[gregp]

I am "attempting" to build a new program using routines from an existing program (which is running under DVF). I have set all the "Project Settings" to match. I have explicitly included LIBC.LIB in the no default lib, exactly as in the original, running program. When I attempt to build the new program (only one routine, the "main" is different), I get dozens of LNK2005 errors saying there is a conflict between LIBC.LIB and LIBCMT.LIB.

Obviously there are settings that are selected by the programming environment that are not visible in the SETTINGS box. How do I find where they are hidden so I can make a new project that matches the settings of existing ones? I have tried the "save environment" both this time and in the past, and using the "saved" environment for the new project (as I did this time, using the working environment from the program with the common routine as the saved one) and it still doesn't work.

This problem (of not being able to get a working environment even though it is modeled on one) keeps recurring almost every time I need to create a new program. I don't make a lot of new programs (maybe a couple a year), but I can almost never get it to create a new, simple program without at least a day of hassles and tracking down errors from the system, not from my code. Oh how I long for the simplicity of Fortran 5.0 (which I still use whenver I can as it NEVER has a problem with project settings).

Here are the specifics for version, etc:
Windows NT 4.0 SP4
Visual Fortran Professional Edition 6.1.0
Compaq Visual Fortran 6.1-845-4297N
Compaq Visual Fortran 6.1-139

-Greg

[Steven_L_Intel1]

The "'no default library" setting is usually the wrong choice - better is to make sure that all the code is compiled with consistent settings for Libraries. Please see this Newsletter article on the subject.

When you compile a source, the compiler writes into the object file the libraries it wants to link against - these are the default libraries. Since LIBCMT is in there, you must have something compiled multithreaded.

CVF 6.6 has revamped the Libraries settings box to be more consistent with Visual C and easier to understand.

Steve

[gregp]

Not likely. I've never used anything but "single graphics window" and "standard console" projects. The new project is explicily re-compiling the routines borrowed from the running project. I only link to one "user" routine library, the same one is for the project the works.

If it thinks there is a multi-thread routine somewhere, how would one find it?

I deleted everything from the project, created it again from scratch using the saved environment (same as before), added the nodefaultlib libc.lib .... and now it will compile and link.

Of course it still won't run, as the call to GETENVQQ doesn't work in this program (the returned string length is -2147483648, and yes it is an integer*4 variable), although the exact same routine that is calling GETENVQQ still works if I recompile everything in the original program (which I did earlier this morning).

Is my copy of DVF corrupted and just spewing out garbage?

-Greg

[gregp]

Dumb DUmb DUmb.

I read the article on multi-thread libraries, so tried to rebuild my link library telling it to use "standard graphics". The library build "Seemed" to go ok. When I then told it to rebuild everything for my new project, it came up with errors for just about everything (47 of them).

Problem is, building the library again with the original settings (again no errors in that setp), then rebuild all of the new project and ALL OF THE ERRORS ARE STILL there. It did not build the program like it had only 5 minutes earlier.

Obviously something is VERY wrong with this picture.

-Greg

[Steven_L_Intel1]

I see you're getting help from our expert in this area through vf-support, so won't continue here.

Steve