4 Replies Latest reply on Sep 13, 2007 9:13 AM by illenseer

    cannot find some LAPACK symbols in 'libacml_dll.dll'

    abhivg
      Hi,

      I am trying to build and link some Fortran code which uses LAPACK routines. I am using ACML 3.6.0 with PGI fortran compiler.
      When I try to link using the dynamic ACML library (libacml_dll.lib), I am getting the following error:

      slassq_test.obj : error LNK2019: unresolved external symbol slassq_ referenced i
      n function MAIN_
      test.exe : fatal error LNK1120: 1 unresolved externals


      If I link using the static ACML library (libacml.lib). it links fine.

      I tried using 'dumpbin.exe' to see which symbols are supported by libacml.lib and libacml.dll, I observed that the dll doesnt have some symbols present in the lib including 'slassq_'.

      Doesn't the dll version support all the LAPACK functions supported by the lib version?
      Do I need to use some PGI fortran compiler flags while linking with libacml_dll.lib?

      thanks in advance
      Abhishek
        • cannot find some LAPACK symbols in 'libacml_dll.dll'
          chipf
          The problem occurs because we only export to the DLL the routines named in our acml.h. Since slassq is an auxiliary routine, we didn't put it in acml, hence it is not in the dll. This is an oversight, and we'll have to investigate the best way to resolve it.

          As a quick solution, you could download the FORTRAN source from the netlib web page. I found it using the Explore LAPACK code by routine name link, but google would likely find it even faster.
            • cannot find some LAPACK symbols in 'libacml_dll.dll'
              illenseer
              Hi,

              same problem for me: I also ran into this and I am missing the

              CLASSQ
              ZLASSQ

              symbols. So together with the first post all *lassq routines are missing from the DLL versin of ACML. So I assume that (as chipf states) all auxiliary routines might not be in the DLL? - I'd really appreciate to have them also be exported in the DLL version.

              I already filed a support request on 2007-08-31, but did not receive any answer yet.
              My eMail was:

              Dear Sir or Madam,

              I found at least two functions missing from the DLL version of ACML
              (i.e. "libacml_dll.lib") whereas the same functions are there in the
              static version of ACML (i.e. "libacml.lib"). We are currently using
              ACML version 3.6.0 compiled with IFORT for both Windows 32bit and
              Windows 64bit and both versions show the same missing functions.
              The two functions (I am currently missing) are:

              CLASSQ
              ZLASSQ

              from LAPACK. See the following commands for reference:

              $ dumpbinlibacml.lib /SYMBOLS | grep -i class
              011 00000000 UNDEF notype () External | _CLASSQ
              011 00000000 UNDEF notype () External | _CLASSQ
              011 00000000 UNDEF notype () External | _CLASSQ
              014 00000000 UNDEF notype () External| _CLASSQ
              014 00000000 UNDEF notype () External | _CLASSQ
              014 00000000 UNDEF notype () External | _CLASSQ
              011 00000000 UNDEF notype () External | _CLASSQ
              011 00000000 UNDEF notype () External | _CLASSQ
              014 00000000 UNDEF notype () External | _CLASSQ
              014 00000000 UNDEF notype () External | _CLASSQ
              014 00000000 UNDEF notype () External | _CLASSQ
              01B 00000000 UNDEF notype () External | _CLASSQ
              01B 00000000 UNDEF notype () External | _CLASSQ
              01B 00000000 UNDEF notype () External | _CLASSQ
              SRC_common\classq.f
              008 00000000 SECT2 notype () External | _CLASSQ
              011 00000000 UNDEF notype () External | _CLASSQ
              013 00000000 UNDEF notype () External | _CLASSQ
              00E 00000000 UNDEF notype () External | _CLASSQ

              $ dumpbin libacml.lib /SYMBOLS | grep -i zlass
              011 00000000 UNDEF notype () External | _ZLASSQ
              011 00000000 UNDEF notype () External | _ZLASSQ
              011 00000000 UNDEF notype () External | _ZLASSQ
              014 00000000 UNDEF notype () External | _ZLASSQ
              014 00000000 UNDEF notype () External | _ZLASSQ
              014 00000000 UNDEF notype () External | _ZLASSQ
              011 00000000 UNDEF notype () External | _ZLASSQ
              011 00000000 UNDEF notype () External | _ZLASSQ
              014 00000000 UNDEF notype () External | _ZLASSQ
              014 00000000 UNDEF notype () External | _ZLASSQ
              014 00000000 UNDEF notype () External | _ZLASSQ
              01B 00000000 UNDEF notype () External | _ZLASSQ
              01B 00000000 UNDEF notype () External | _ZLASSQ
              01B 00000000 UNDEF notype () External | _ZLASSQ
              SRC_common\zlassq.f
              008 00000000 SECT2 notype () External | _ZLASSQ
              012 00000000 UNDEF notype () External | _ZLASSQ
              013 00000000 UNDEF notype () External | _ZLASSQ
              00E 00000000 UNDEF notype () External | _ZLASSQ

              $ dumpbin libacml_dll.lib /SYMBOLS | grep -i class
              $ dumpbin libacml_dll.lib /SYMBOLS | grep -i zlass


              I.e. the last two commands generate no output, whereas the static
              version shows the two functions I need!
              Also when looking with the dependency walker (depends.exe) at the
              dll "libacml_dll.dll", I cannot find either of the two above functions.

              This is a showstopper for our product, as we need these two functions
              to be called from ACML.
              Also with my last eMail from 2007-07-03 08:48 (MEST) I am no longer
              able to find any workaround for successfully compiling our product.
              So from my point of view there are two possibilities:

              a) Provide a static version of ACML (compiled with IFORT) which
              des NOT link against the MSVCRT v8.0 (i.e. the dependency on
              "msvc80.dll" shall not occur).

              b) Include the two missing functions as exports in the dynamic
              version of ACML so that they can be called from the dll.

              Please provide any solution as soon as possible, so that we can continue
              to build and ship our product with ACML.

              Thank you very much in advance.


              Best regards,
              Frank Illenseer
                • cannot find some LAPACK symbols in 'libacml_dll.dll'
                  chipf
                  This problem should be resolved in ACML 4.0.0 that was posted yesterday.

                  When I try to use link /dump /symbols, the dll file does not show the *LASS* entries. But link /dump /exports shows that they are there. They weren't there in 3.6.0, and this is one of the changes we made for the new rev.

                  We did not export all of the LAPACK utility routines, but hopefully the set we chose will meet the widest set of needs.
                    • cannot find some LAPACK symbols in 'libacml_dll.dll'
                      illenseer
                      Yes, indeed the symbols are there now in the DLL version!
                      (I tested windows 32 and 64 bit compiled with Intel FORTRAN compiler.)

                      $ dumpbin libacml_dll.lib /EXPORTS | grep -i lass
                      _CLASSQ
                      _DLASSQ
                      _SLASSQ
                      _ZLASSQ
                      _classq
                      _dlassq
                      _slassq
                      _zlassq

                      $ dumpbin libacml_dll.dll /EXPORTS | grep -i lass
                      213 D4 0006B028 CLASSQ
                      463 1CE 000ED620 DLASSQ
                      812 32B 0018AA10 SLASSQ
                      1202 4B1 00246A54 ZLASSQ
                      1486 5CD 002876C0 classq
                      1689 698 0028E780 dlassq
                      1990 7C5 00297EE0 slassq
                      2320 90F 002A3B70 zlassq


                      And then linking works as expected and without any unreslved symbols.
                      Just a hint: As "chipf" stated one has to use the "/EXPORTS" switch t get them from either "link" or "dumpbin". ("/ALL" for "dumpbin" also works.)

                      Thank you for adding this.
                      Regards,
                      Frank