configure failed with ifort 18 and xmlf90 >= 1.5.2

[jmbeuken]

ifort 18.0
libpsml-1.1.7-pre1
xmlf90-1.5.2 ( make check : ALL PASSED )

-----------------------------------------------

configure:15989: checking whether the XMLF90 library works
configure:16003: ifort -o conftest -g -I/usr/local/fallbacks/intel/18.0/serial/libxc/3.0.1/include -I/usr/local/fallbacks/intel/18.0/serial/xmlf90/1.5.2/include -I/usr/local/fallbacks/intel/18.0/serial/libxc/3.0.1/include -I/usr/local/fallbacks/intel/18.0/serial/xmlf90/1.5.2/include conftest.F90 -lxmlf90 -L/usr/local/fallbacks/intel/18.0/serial/libxc/3.0.1/lib -lxcf90 -lxc -L/usr/local/fallbacks/intel/18.0/serial/xmlf90/1.5.2/lib -lxmlf90 >&5
conftest.F90(3): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [M_DICTIONARY]
      use xmlf90_sax
----------^
conftest.F90(5): error #6457: This derived type name has not been declared. [XML_T]
      type(xml_t) :: fxml
-----------^
compilation aborted for conftest.F90 (code 1)
configure:16003: $? = 1
configure: failed program was:
| program main
|
| use xmlf90_sax
| character(len=80) :: fname
| type(xml_t) :: fxml
| integer :: iostat
| call open_xmlfile(fname,fxml,iostat)
| call close_xmlfile(fxml)
|
| end
configure:16010: result: no

[Alberto Garcia (albertog)]

Hi, Jean Michel,

I cannot reproduce the bug... and the official libpsml's latest version is 1.1.6.
Maybe v 1.1.7-pre1 must be some fallbacks special version?

 Best regards,

  Alberto

[Yann Pouillon (pouillon)]

Yes, it is a fallbacks-specific version until Abinit fully supports the new LibPSML API.

[Yann Pouillon (pouillon)]

I've been able to reproduce the issue with Intel 2018.1 64 bits on Ubuntu 16.04. I'll now try to figure out whether it comes from the compiler or the source code.

[Yann Pouillon (pouillon)]

P.S.: It was with XMLF90 1.5.3 (check, distcheck and distcleancheck pass) and LibPSML 1.1.7.

[Yann Pouillon (pouillon)]

I confirm that the problem is reproducible with XMLF90 1.5.3 using the following compilers:

  - Intel 2017.0
  - Intel 2017.4
  - Intel 2018.1

LibPSML is not able to use XMLF90's modules, although "make check" succeeds within XMLF90. It looks like ifort doesn't like "meta-modules" that just re-export variables from the modules they use.

I've unsuccessfully tried to solve the issue by explicitly re-declaring the public symbols in the xmlf90_* meta-modules. It just moves the problem to "unresolved symbols" errors at link-time.

The only way I can imagine to solve this issue is to redesign the whole hierarchy of modules in XMLF90 so that exported symbols are directly used by dependent libraries and programs. I'll write a blueprint for this.

To clarify things: this problem is vendor-specific. GCC doesn't have any trouble compiling and using XMLF90's modules as they are now.

To clarify even more: this is NOT a problem of LibPSML.

[Alberto Garcia (albertog)]

Hi,

Could it be that the "main" module files are discoverable (through the -I/path/to/include mechanism) but
for some reason the "referenced" module files are not installed in the same way, and are not discoverable?

Note that " >= 1.5.2" means that the issue might be autotools-related.

----- El 22 de Feb 2018, a las 18:23, Yann Pouillon <email address hidden> escribió:

| I confirm that the problem is reproducible with XMLF90 1.5.3 using the
| following compilers:
|
| - Intel 2017.0
| - Intel 2017.4
| - Intel 2018.1
|
| LibPSML is not able to use XMLF90's modules, although "make check"
| succeeds within XMLF90. It looks like ifort doesn't like "meta-modules"
| that just re-export variables from the modules they use.
|
| I've unsuccessfully tried to solve the issue by explicitly re-declaring
| the public symbols in the xmlf90_* meta-modules. It just moves the
| problem to "unresolved symbols" errors at link-time.
|
| The only way I can imagine to solve this issue is to redesign the whole
| hierarchy of modules in XMLF90 so that exported symbols are directly
| used by dependent libraries and programs. I'll write a blueprint for
| this.
|
| To clarify things: this problem is vendor-specific. GCC doesn't have any
| trouble compiling and using XMLF90's modules as they are now.
|
| To clarify even more: this is NOT a problem of LibPSML.
|
| ** Summary changed:
|
| - configure failed with ifort 18 and xmlf90-1.5.2
| + configure failed with ifort 18 and xmlf90 >= 1.5.2
|
| ** Changed in: libpsml
| Importance: High => Medium
|
| ** Changed in: libpsml
| Status: Confirmed => Triaged
|
| ** Also affects: xmlf90
| Importance: Undecided
| Status: New
|
| ** Changed in: xmlf90
| Status: New => Triaged
|
| ** Changed in: xmlf90
| Importance: Undecided => High
|
| --
| You received this bug notification because you are subscribed to
| libPSML.
| https://bugs.launchpad.net/bugs/1739443
|
| Title:
| configure failed with ifort 18 and xmlf90 >= 1.5.2
|
| Status in libPSML:
| Triaged
| Status in xmlf90:
| Triaged
|
| Bug description:
| ifort 18.0
| libpsml-1.1.7-pre1
| xmlf90-1.5.2 ( make check : ALL PASSED )
|
| -----------------------------------------------
|
| configure:15989: checking whether the XMLF90 library works
| configure:16003: ifort -o conftest -g
| -I/usr/local/fallbacks/intel/18.0/serial/libxc/3.0.1/include
| -I/usr/local/fallbacks/intel/18.0/serial/xmlf90/1.5.2/include
| -I/usr/local/fallbacks/intel/18.0/serial/libxc/3.0.1/include
| -I/usr/local/fallbacks/intel/18.0/serial/xmlf90/1.5.2/include conftest.F90
| -lxmlf90 -L/usr/local/fallbacks/intel/18.0/serial/libxc/3.0.1/lib -lxcf90 -lxc
| -L/usr/local/fallbacks/intel/18.0/serial/xmlf90/1.5.2/lib -lxmlf90 >&5
| conftest.F90(3): error #7002: Error in opening the compiled module file. Check
| INCLUDE paths. [M_DICTIONARY]
| use xmlf90_sax
| ----------^
| conftest.F90(5): error #6457: This derived type name has not been declared.
| [XML_T]
| type(xml_t) :: fxml
| -----------^
| compilation aborted for conftest.F90 (code 1)
| configure:16003: $? = 1
| configure: failed program was:
| | program...

[Yann Pouillon (pouillon)]

I looked at the differences between versions 1.5.0 and 1.5.3 and saw that the former was installing all Fortran modules, while the latter only installs the upper-level ones (xmlf90_*.mod).

This is fine with gfortran which is able to resolve the symbols using the libraries, but ifort does requires that all modules be installed to successfully resolve the dependencies.

I've explored various ways to make things more flexible. My proposal is in my "portability" branch of XMLF90. This is currently a quick fix which could be refined by detecting the Fortran compiler vendor and installing modules depending on the result.

Could this become the 1.5.4 version of XMLF90?