-standard-semantics and linking with external libs

[Jacob_Williams]

It seems as if there are some linking restrictions that happen when you use the -standard-semantics flag on Linux? I'm trying to link statically to the HDF5 library fortran interface. My main code is using -standard-semantics. For example, consider some simple case where I'm just calling a routine in the library called h5get_libversion_f:

    ifort hdf5_test.f90 -I./include/static -c

    ifort hdf5_test.o ./lib/libhdf5_fortran.a ./lib/libhdf5_f90cstub.a ./lib/libhdf5.a -lz

This works and runs fine.

Now, when I use:

    ifort hdf5_test.f90 -I./include/static -c -standard-semantics

    ifort hdf5_test.o ./lib/libhdf5_fortran.a ./lib/libhdf5_f90cstub.a ./lib/libhdf5.a -lz

I get the linker error:

    hdf5_test.o: In function `MAIN__':
    hdf5_test.f90:(.text+0x49): undefined reference to `h5lib_MP_h5get_libversion_f_'

I presume this has to do with the fact (I think) that the -standard-semantics flag is mangling the routine with "MP" rather than "mp". I also presume that HDF5 is not using this flag.

So, is there a restriction that all the code and libraries in a project have to either use or not use this flag consistently? Is there any way around this? Mainly I'm using this flag for other reasons, and I don't really care about the alternate mangling (is there any way to keep the flag but disable this one aspect?) I would rather not have to mess with the HDF5 settings if I can help it.

Any help is appreciated!

[Jacob_Williams]

BTW, I don't think it much matters, but the test program is attached for completeness:

program hdf5_test

    use hdf5

    implicit none

    integer :: majnum, minnum, relnum, ierr

    call h5get_libversion_f(majnum, minnum, relnum, ierr)

    write(*,*) majnum, minnum, relnum, ierr

end program hdf5_test

[Juergen_R_R]

I build hdf5 with the ifort compiler (v19), as well as followed your linking steps. Compiles, links, and gives the output

 1          10           4           0.

Did you use a precompiled hdf5 library?

[jimdempseyatthecove]

Juergen,Jacob,

Can you please comment on a new thread in this forum Array Visualizer...

Jim Dempsey

[Juergen_R_R]

Quote:

Juergen,Jacob,

Can you please comment on a new thread in this forum Array Visualizer...

Jim Dempsey

Jim, I fear I cannot really contribute, I build the library today for the first time, because I was just interested in the test case in this thread. My apologies.

[jimdempseyatthecove]

Juergen,

No problem, thanks for replying.

IMHO the former Intel Array Visualizer & Viewer put the Visual in Intel Visual Fortran. I hope that they reconsider a new integration of the current code base complete with the capability of the former product: Multiple processes viewing the HDF5 database while a separate process is producing/modifying the database. This was extremely valuable as it permitted the observation of a simulation run without the fear of the observation killing the run. Somewhat like Schrödinger being able to peek in the box without killing the cat.

Jim Dempsey

[Jacob_Williams]

Juergen,

Well that's interesting. You built the static libs on Linux, with the 64 bit compiler and the case above worked with the -standard-semantics flag? How did you build it? Did you change any of the compile options?

I used CMake, but with v17.0.2 of the compiler. I will update soon to v19 to see if that makes any difference, but not sure it will.

[Juergen_R_R]

Jacob,

sorry I overlooked the -standard-semantics flag. Indeed, with the flag during compilation I get the error as described by you, also with v19. Your observation with the name mangling also seems to be correct.  Possibly you are correct, and the compiler flags need to be the same.

[Lorri_M_Intel · Accepted solution]

-standard-semantics does, in fact, change the name mangling for module procedures. 

You can override just that feature of standard-semantics by adding "-assume nostd_mod_proc_name" to your compile line, after the -standard-semantics switch.

           --Lorri

[Jacob_Williams]

Yes, I just discovered that one! I can confirm that adding "-assume nostd_mod_proc_name" after "-standard-semantics" does indeed fix the issue.

Maybe this is an issue that should be more clearly mentioned in the documentation (if it isn't already?). It seems a significant issue that might be hard for someone to diagnose unless they knew what they were looking for.

[jimdempseyatthecove]

Lorri,

In the example case above the libhdf5 was apparently compiled without the -assume nostd_mod_proc_name corrected for this. What is going to happen if the program also calls into a library build with -standard-scmantics? Is there a solution to this?

Jim Dempsey

[Lorri_M_Intel]

OK, I get what you're asking (I had to read it a couple of times).  There is no easy solution, at least not off the top of my head.

[jimdempseyatthecove]

The code that generates the library can create the code with one entry point with two names:

h5lib_MP_h5get_libversion_f_:
h5lib_mp_h5get_libversion_f_:
      code...

Both being exported.

Jim Dempsey

[mecej4]

Jim, I suspect that the different name mangling exists for a reason: routines compiled with -standard-semantics may not be 100 percent compatible with other routines compiled without that option. The Intel people may have a list of all the changes in code generation that are related to that option. If we attempt to fool the linker without being aware of those incompatibilities, we can get into trouble. Perhaps Lorri can comment on this question.

[jimdempseyatthecove]

Mecej4,

I disagree. What you are arguing for is the choice of use or lack thereof for code compliance of the source code within the compiled procedure(s) within an external library. Whereas, may argument position is for maintaining a consistent API regardless of compiler options and or language used in the procedure. IOW it is not the purview of the calling program to dictate how the underlying code of library function was produced. The only requirements are: what is the API, and that it works.

Jim Dempsey

[Steve_Lionel]

The reason for the difference is that on Linux (and Mac), the compiler's name-decoration convention for module procedures could conflict with a user-written procedure's name. (This issue doesn't arise on Windows.) Unfortunately, the fix for this does introduce an incompatibility with previously compiled modules.