DISLIN

[JohnNichols]

I downloaded latest version,

then checked and it compiled and ran

pulled out the first legacy library and I get the following error

I am pretty sure that the main guys on this site have explained before what happens and why they are needed. 

I run the latest W11 Preview build canary version, obviously someone at Microsoft has a sense of humour the old canary in the coal mine was telling you, you were about to die.  

Latest VS that will take ONEAPI and I do a nearly full installation and a complete ONEAPI.  

I was on a university computer yesterday, had a quick look at the OS, they are running version that is more than 2 years old, interesting.  

[andrew_4619]

So if you remove the disifl??? libs from the build (clearly you will get unresolved dislin calls) does the fprintf go away?

[Andreas_Z_]

As mentioned in the other recent thread with the same title: have you made sure to set in VS project properties under
Fortran > Libraries > Runtime Library:
Debug Multithreaded (\libs:static /threads /dbglibs)
or simply
Multithreaded
(depending on Debug vs Release mode); the point is to have linking with static libraries rather than with DLLs selected.

If you link against the DLL version, which is the default option, you get the fprintf errors.

[JohnNichols]

I cannot get your ideas to compile, I made sure to set up exactly as shown, I have been doing this for a while with DISLIN and it keeps throwing routine not found errors., under every combination.   

It works and I am happy, maybe it is time to consider another problem,

Say the meaning of life

I was looking for the Dave Allen sketch about security in the 1990s in getting into a TV studio when he climbed down a rope in black, but I could not find it, as a passing reference to the humour of the new Intel Login 

but I found this Dave Allen comment and seeing the number of retirees on this site I thought you would get a chuckle (it is cleaned up)

You wake to the clock, you go to work to the clock, you clock-in to the clock, you clock out to the clock, you come home to the clock, you eat to the clock, you drink to the clock, you go to bed to the clock, you get up to the clock, you go back to work to the clock... You do that for forty years of your life and you retire — what do they .......  give you? A clock!

[Andreas_Z_]

... And I thought the meaning of life was to successfully link to Dislin ;). 

Anyways, if you still want to go down that rabbit hole with your project, please post your Fortran project command line from VS. All I can mention is that I have none of the stated issues in the various program I have that are using Dislin. However, when I have the "/libs:dll" switch set in the project (for sake of testing) I get precisely the errors you report. In that sense, I would not blame Dislin for that, but incompatible use of external static libraries.

[JohnNichols]

/nologo /debug:full /Od /I"c:\dislin\ifc\real64" /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc170.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /Qmkl:parallel /c

/OUT:"x64\Debug\HEBE.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"x64\Debug\HEBE.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"B:\Users\macne\Documents\Visual Studio 2017\Projects\Program121 - Dutch Programs\Hebe\Hebe\x64\Debug\HEBE.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"B:\Users\macne\Documents\Visual Studio 2017\Projects\Program121 - Dutch Programs\Hebe\Hebe\x64\Debug\HEBE.lib"

/DEFAULTLIB:gdi32.lib user32.lib
/NODEFAULTLIB:libcmt.lib

[JohnNichols]

Will not compile without the legacy libs. 

[Andreas_Z_]

One way your build command line differs from the ones I see for Dislin-linked projects (currently looking at a VS 2019 project) is under the linker settings; the Fortran command line seem fine. In my case, for the linker command line, i.e. shown as /OUT: ... , I see at the very end the following line: 

c:\dislin\disifl_d.lib c:\dislin\disifd_d.lib user32.lib gdi32.lib

In your case, the user32.lib gdi32.lib are listed under /DEFAULTLIB  (not sure whether that's a VS 2022 change), but the c:\dislin\disifl_d.lib c:\dislin\disifd_d.lib are missing, which would explain why your linking to Dislin fails without the legacy libs.

I set those here:

[andrew_4619]

John you have /Qmkl:parallel which I do not believe is compatible with  /libs:static so I think the later will be ignored and it is thus not a static build. I would check that out you could look at the dependencies of your exe.

[HannaJo]

Hi, I managed to solve this problem by following these steps:

1. Download and install the latest version of DISLIN from https://www.dislin.de/.
2. Copy the file dislin.mod from the folder C:\dislin\ifc to the folder C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\compiler\include.
3. Add the folder C:\dislin to the system environment variable PATH.
4. In Visual Studio, go to Project -> Properties -> Fortran -> General and set Additional Include Directories to C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\compiler\include.
5. In Visual Studio, go to Project -> Properties -> Linker -> General and set Additional Library Directories to C:\dislin.
6. In Visual Studio, go to Project -> Properties -> Linker -> Input and set Additional Dependencies to dislin.lib.
7. Rebuild the project and run the executable.

I hope this helps you and others who are facing the same issue.

Best regards, Hanna from CodeIT 

[JohnNichols]

@andrew_4619  and @HannaJo and @Andreas_Z_ 

In no particular order:

The parallel option is required for MKL. The analysis looks at a reinforced concrete column decay over years and used PARDISO.   The PARDISO that @mecej4 very kindly helped me get right a few years ago.   DISLIN is not the main element, it is just a way to view the data over time.  

if the stress strain curve for steel and concrete was a straight line, this would be easy, but it is only linear to about 30% and then we move into the non-linear region.  The dead load uses up the 30% and so the live load is always non-linear and at high loads highly non-linear.  Plus the highway authorities let people run large loads over the bridges, a really bad idea.  

This is from a program I have mentioned from Canada in the 1970s, I now have it running, but determining how to manage the output in a useful form is being an interesting step. 

The dislin.libs are actually four libraries depending on whether you want single or double precision, of course the examples are in single, so  that it is a first painful step to fix those programs.  

There are many ways to achieve the same thing in the compiling and linking stages, so thank you for the options laid out above.  

In additional dependencies one needs c:\dislin\disifl_d.lib c:\dislin\disifd_d.lib   - 

You also need to use IFORT to compile the mod file for dislin.f90 for your compiler.  

It is the subtle changes that cause havoc as you try and reuse code.  

I was reading up on Fortran last night and several sites basically said for HPC you can use Fortran or you can not do real HPC.  C++ was discounted for real high speed work. 

I have at least one of Michael Metcalf's books, but I could not find a website for him, does anyone know where he works, or does he just write.  

Say what you like, this is still one of the three best websites in the world, with The Guardian and Lakeland Cam, one can lead a comfortable life with them each day.  

[andrew_4619]

I have little interest in bridge and RC calcs, I stopped doing that stuff in 1988.  The 'problems' you have had are a result of mixing objects with static and dynamic linkage. Using the correct build options AND the compatible dislin libraries (they supply both  dll and static lib linkage versions) would remove these issues without needing cludge.  I am not sure where "legacy libraries" come into it I don't see any. Maybe you are confusing with when in days of old "OLDNAMES.LIB" was needed to manage name differences?  The gdi32/user32 libs are just standard (current) windows sdk libraries.

[JohnNichols]

The cludge is resolved, I got rid of the legacy files, you just have to put c:\dislin\disifl_d.lib c:\dislin\disifd_d.lib in the dependent list, which is contrary to the writers READ.ME file.  

We are all interested in RC calcs, most of the bridges in the world are built with a 50 year life (reality) and most of them are approaching an average of 50 years.  Fortran is the best language to do rapid analysis of these bridges, we prefer that people do not die unnecessarily. 

[andrew_4619]

Hmmm. The disifl_d.lib disifd_d.lib are static and dynamic versions of the same library so I am guessing that either the linker is smart enough to work it out or maybe it links with the first it finds a resolution with or maybe........ as you have  /Qmkl:parallel dynamic linking is the only option you have......

[JohnNichols]

I have used DISLIN for a few years, it is always interesting to update programs for the new version as the author makes subtle changes, names etc.  A long time ago I stopped trying to solve what is inside locked code, it works, now it is documented here so others can find it, we cannot do much better than that. 

The read me notes say

The Dislin libraries disifl.lib and disifl_d.lib are compiled
with the option /MT (Multithreaded). If you want to link for
Multithreaded DLL runtime libraries (/MD), you can link with the
Dislin libraries disifd.lib or disifd_d.lib.

So I tried just using the l_d library and it worked. So now I am fully conforming, except for the libcmt.