cDEC$ Attributes Dllexport can cause linker to hang on 64-bit builds

[John6]

I have attached a small solution which includes the line "cDEC$ ATTRIBUTES DLLEXPORT :: Fx1" (which came from some legacy stuff from a larger app). The solution is a Windows Console App main program calling a static FORTRAN lib. The build is 64-bit. The line mentioned above causes the linker to hang. If it is commented out, everything builds OK.
I know the easy solution is to simply comment the line out with a "!", but is there some switch which addresses this? I would think that if the linker failed, a message should be given to the user. In this case, it just continues to try and link with no error. This only seems to happen for 64-bit builds. The IDE is VS 2005 and the IVF version is 11.1.051

[Steven_L_Intel1 · Accepted solution]

It's the Intel prelinker, xilink.exe, that is hanging. I'll report that to the developers. Here's a workaround.

Open the compiler's binintel64 folder. Rename xilink.exe to xilink_orig.exe. Open the Visual Studio 8.0VCbinamd64 folder. Copy link.exe into the compiler's binintel64 folder and then rename it to xilink.exe.

You won't be able to use the /Qipo option with this, but you will be able to build your project.

[abhimodak]

Hi

I cannot reproduce this problem when using WinXP64 with VS2005. The build goes fine for both win32 and x64 builds (both in debug as well as release mode).

However, when I use "rebuild solution" WITHOUT cleaning the solution, I get the following error:

Error 1 fatal error LNK1181: cannot open input file 'C:AbhiMySourceTestsTest_Link64Libx64Releaserefprop7.lib' LINK

This error happens for both win32 and x64 and for both debug and release modes.

On the other hand, I have quite similar isse mentioned here:
http://software.intel.com/en-us/forums/showthread.php?t=70171

I had tried the method Steve has mentioned but it did not work. I will try it again to make sure that I did it right. I don't think it is possible to go through all our programs and change the c$DEC line.


Abhi

[Steven_L_Intel1]

Abhi,

The error you ran into is because the solution is configured to have both projects share a single output directory. As I noted, that doesn't work. I saw the hang problem after I fixed that.

Note that the hang is if you are building an executable and there is a DLLEXPORT directive - an unusual choice.

[abhimodak]

Hi Steve

My mistake. It sounded similar to what I am experiencing and I went in Eureka mode!

In my case (as posted previously) I see that fortcom.exe hangs (i.e. the task manager shows that it is running). I will try to create a sample solution; it will be a mixed-langauge project. We do not use the latest compiler for production so it has taken a low priority for me.

Abhi

[Steven_L_Intel1]

I could reproduce the problem, with fortcom.exe going CPU-bound, given what was in this thread (with a few changes). Is your problem different?

[John6]

Quoting - Steve Lionel (Intel)

Abhi,

The error you ran into is because the solution is configured to have both projects share a single output directory. As I noted, that doesn't work. I saw the hang problem after I fixed that.

Note that the hang is if you are building an executable and there is a DLLEXPORT directive - an unusual choice.

Building an executable with the DLLEXPORT directive is an unusual choice. The directive is from a legacy application which was not actually being used (but caused no harm under a 32-bit build, so I saw no reason to modify it). When I went to compile the app for a 64-bit build, I noticed the hang and had to narrow it down to isolate. Abhi, your LNK1181 error was probably caused by my original failure to clean the solution up a bit before posting. Steve, thanks for the workaround. I simply commented all references to it out and everything worked perfectly.

[Steven_L_Intel1]

This seems to be fixed in Update 5 (11.1.060).