Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

read namelist from string broken?

Zapp_O_
Beginner
532 Views

I use Intel(R) Visual Fortran Composer XE 2011 Update 6 Integration for Microsoft Visual Studio* 2010, 12.1.3514.2010 and face a strange compiler/linker problem. The program below tries to parse an argument list from a string using a namelist but fails at linking with an unresolved symbol "_for_read_int_nml".

[fortran]

program namelisttest
        character(len=255) :: buffer, str1, str2
        namelist /arglist/ str1, str2
        buffer = "&arglist str2='test string' /"
        read(buffer,nml=arglist)
        write(*,arglist)
end program
[/fortran]

I tested this under linux (ifort and gfortran) without any problems. Is this a bug in the compiler, since it searches for _for_read_int_nml (instead of _for_read_seq_nml) ?

Is there a workaround (except writing a temporary file) or a better way for parsing a string into several fields?

Thanks in advance

0 Kudos
6 Replies
Steven_L_Intel1
Employee
532 Views

I can't reproduce this with that (or any other) version - my guess is that your library path is incorrect somehow. Are you building from within Visual Studio or from the command line? Please show the build log (if using VS, attach a ZIP of buildlog.htm from the Debug or Release folder.) It would also be helpful if you enabled Linker > General > Show Progress > Display Some Progress Messages. From the command line, add /link /verbose:lib to the end of the ifort command line.

I would comment that NAMELIST is a rather strange approach for the task you describe.

0 Kudos
Zapp_O_
Beginner
532 Views

Hello Steve,

thanks for your response. I'll try to provide all the debug information you mentioned. However this has to wait a few hours for me being back in the office. In the meanwhile somewhat more "offline"-information: I'm building within Visual Studio. I tried this example with a new wizard-created project without any modifications and again on a colleague's computer (with a slightly more up-to-date version of Visual Fortran) - everywhere the same linkage error. Anyway ... let's come back to this after analyzing the debug information.

About your comment: using NAMELIST to parse an option character string without the hassle of tokenizing it the hard way seemed to be an elegant and quite portable (among different fortran compilers) way. However, any suggestions to reach this without "abusing" NAMELIST would be greatly appreciated.

0 Kudos
Steven_L_Intel1
Employee
532 Views

If your option string was written using NAMELIST, then that's fine. I thought you were trying to use it for generic parsing.

0 Kudos
Zapp_O_
Beginner
532 Views

Well, some more results of my further explorations on this problem:

After checking all library paths and so on I still get the linkage error for all projects that use /libs:dll (and yes, it links successfully for /libs:static). And indeed, the symbol seems to be missing in my libifcoremd.dll (as far as dependency walker [http://www.dependencywalker.com/] or http://www.boostbyreason.com/resource-file-32617-libifcoremd-dll.aspx is telling me). So, is this on purpose? Under linux (libifcoremd.so.5) the symbol is there, too.

Please see also the files of my test project and the build log in Debug, that I attached ...

Thanks again for your support.

0 Kudos
Steven_L_Intel1
Employee
532 Views

Thanks for the added detail, which was critical. This is NOT intentional - it's a bug. It is still broken in the current release. Amazing that this wasn't noticed before.  I will escalate this to development immediately. Issue ID is DPD200249837. All I can suggest for now is to link statically if you can.

0 Kudos
Steven_L_Intel1
Employee
532 Views

This will be fixed for Update 2, planned for January. It's something that got overlooked when we implemented NAMELIST internal I/O and you're the first to try that with DLL linking (though that becomes more likely with compiler version 14 as we now default to that in new projects.) We apologize for the inconvenience and thank you for bringing it to our attention.

0 Kudos
Reply