Problem with GETCWD subroutine (?)

[WSinc]

This is supposedly part of the Fortran library.

It's supposed to return the "full directory path" of the current working directory,

according to the blurb in the on-line help.

What it does do (for me anyway) is return all blanks with a status of 0.

Am I doing this right?

Is this the right routine for that?

Maybe there is something that works better?

Please elucidate....

[bash]--------------------------------------------------------------------------------------------------------

       subroutine  test_getcwd

       use ifport

       character*80 cwd

       integer(4)  istat

       istat=getcwd(cwd)

       print *,"istat=",istat

       print *,"cwd=",cwd

       end subroutine



[/bash]

[victor_pp]

It worked for me:

D:\tmp>test_gcwd

istat= 0

cwd=

D:\tmp.

It only prints thefull directory pathon the new line.

Victor

[WSinc]

Hello Victor -

That looks like something from the command line.

Were you using Fortran code?

If so, please show me the Fortran code.

I was trying to call the subroutine from within Visual Studio and a Fortran program.

The Character variable should contain the full directory path, but for me it contained all blanks.

I looked at it with the debugger also.

Please refer to my example code.

[Les_Neilson]

Bill

Running your code both as a subroutine and as a programit printsmy current directory no problem

Les

[WSinc]

Boy, this is weird ! !

I wonder if something in my current environment is triggering this problem....

As far as I know, no one on the forum does a "remote assist,"

so I don't know how to examine it in my environment.

I have VS 2008.

Thanks for your reponses.....

[Steven_L_Intel1]

Bill,

I think I have told you twice already that we are capable of doing a "remote assist", but perhaps it would help if you would show us the actual output of the program (and what you have posted is not a program), as well as what you think it should be returning. Is the full path longer than 80 characters?

[WSinc]

I was able to get it to work ....

But I had to lengthen the CWD variable to 160 characters, then it worked fine.

Regarding "remote assist," I've never used it in your forum before. I know the "paid for" support people have it.

I think where I need it the most is when something hangs up the EXE file I've just built. It's more than just a nuisance, before it normally requires me to force a power-off reboot. Whatever it is also sometimes hangs up the MT.EXE file, I guess that's an intermediate step in the build.

So, a remote assist possibly could enable someone to figure out what's grabbing the EXE. My theory is that the DEVENV process does not completely terminate and is still grabbing a file "handle."

So if there's a way to invoke it when it happens again, it would be very helpful.

Incidentally, when I send an EXE to someone, what else has to be included along with it?

That story about the licensing of EXEs came from someone in your support department several years ago,

and I could try to dig it up.

I thought the EXEs are self-contained, i.e. the executables are complete. Of course, data files would

have to be sent along as well. Is this incorrect? Are there any articles about this subject?

[Steven_L_Intel1]

We don't normally do remote assist, but will do so when it seems required.

An EXE may or may not be self-contained, depending on how it was built. It may depend on DLLs that have to be present on the target system. Programs linked against the "Debug" DLL libraries are not redistributable. In any event, there are no conditions attached to your executables from either Intel or Microsoft. (If you are using IMSL, there are restrictions from Visual Numerics on where you can run the executable.)

If you want to send us a test case, the best thing is to attach a ZIP of the project so that we can see all the sources and the project settings.

[WSinc]

I would be happy to do that -

The only catch is - the EXE does not hang up all the time.

I'd say about 20 percent of the builds have a problem. Not enough to be serious,

but enough to be annoying.

It seems to be a random occurrence, which makes it hard to track down.

So if I send it to you, chances are that you won't see any problems,

but next time it happens, I can send the last build that DID work, or send

the project files that were in it when it hung.

In the meantime, I can do some experimenting re sending an EXE around.

Are you saying that if I build a "release" configuration, it should be redistributable?

If there is a writeup about this process, it would be very helpful, not only to me,

but to others that want to export their work. At least I don't use IMSL.

[Steven_L_Intel1]

I don't know what kind of a writeup you are looking for. How to build an application? Yes, a Release build should be able to run on other computers - as long as any DLL references are satisfied. (By default, a normal executable is not linked to DLLs.) In any evemt, the hang you are experiencing has nothing to do with licensing.

For information on redistributable DLL packages, see:

Redistribution of Application Binaries Built for Microsoft Windows*

Redistributable libraries for the Intel C++ and Visual Fortran Compiler for Windows

[WSinc]

OK, I will take a hard look at those, and experiment some. Thanks for sending those references.

Re the "Hang" I guess the only way to proceed is to send you the entire project with all the source files, etc.

But it probably won't hang on your end, 'cause your environment is different.

I was wondering - if I buy the support package for one year, would someone be able to get on MY computer and try to figure out what is attaching the EXE? Or can that be done without using remote assist?

The reason I don't think it's within my project is - when I do a rebuild without changing anything, it goes to completion, provided I first get rid of the offending EXE it made before. It was inside the project, wouldn't it hang every time?

I guess it's more convenient for everyone if there is a utility I can run in MY environment. The only thing I have

is process explorer, which is really nice, but I'm not sure it'll give us any clues.

[Steven_L_Intel1]

Yes, if you are current on support, we'd be willing to take a look at it on your system.