Uploaded image for project: 'Software Support'
  1. Software Support
  2. SUP-2275

eccodes_f90. depending on an "older" version of the libgfortran

    XMLWordPrintable

Details

    • Cooperating Organisation

    Description

      -------- Forwarded Message --------
      Subject:     A tough problem
      Date:     Tue, 28 Nov 2017 13:57:12 +0000
      From:     Stephen A. Tjemkes <Stephen.Tjemkes@eumetsat.int>
      To:     helpdesk@ecmwf.int <helpdesk@ecmwf.int>

      Hi

      I think I have a tough problem, although I hope that a knowledgeable person will smile at this.

      I have a software distribution which depends on the eccodes distribution. I have downloaded version 2.4.1 and compile this using cmake.
      The code which uses the libeccodes_f90.so library should be a standard fortran90 code.
      However, I run into a difficult problem which I do not understand, except for the fact that during compilation I have the following warning

      Libgfortran.so.3 needed by /opt/conda/lib/libeccodes_f90.so may conflict with libgfortran.so.4

      The error I have is that I read a parameter from the command line using the gfortran extension GETARG. Then when I map the parameter into an integer the program crashes.

      A simple fortran code, with 4 lines doing the same thing does not crash, and is performing as expected.
      Hence I assume it is caused by this conflict mentioned above.

      Question is why is eccodes_f90.so depending on an "older" version of the libgfortran, although both codes are thought to be compiled with the same gfortran. Is there a special setting in the cmake which forces the eccodes compilation to uses the so.3 library?

      The strange thing is that this happens when I build my system inside a docker container. I have not seen this warning in the "normal" world. And in the normal world my code is working fine.

      The fortran versions of the docker and normal world are the same, so is the eccode distribution. So it is an unexpected result that the eccodes_f90.so library build within the docker is depending on a different shared library that in the outside world.

      Thank yo for a suggestion

      stephen

       Any email message from EUMETSAT is sent in good faith but shall neither be binding nor construed as constituting a commitment by EUMETSAT, except where provided for in a written agreement or contract or if explicitly stated in the email. Please note that any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of EUMETSAT. This message and any attachments are intended for the sole use of the addressee(s) and may contain confidential and privileged information. Any unauthorised use, disclosure, dissemination or distribution (in whole or in part) of its contents is not permitted. If you received this message in error, please notify the sender and delete it from your system. 

      Attachments

        Activity

          People

            usv Daniel Varela Santoalla
            est est
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: