4 Replies Latest reply on Jul 1, 2009 6:09 AM by domagoj.saric

    (32bit static) Windows builds with a free Fortran compiler&co.

    domagoj.saric

      1.

      Looking at the archive I found that version 3.6.0 of the ACML is the last one that provides a 32bit static .lib build for the Win32 platform with a free (GNU) Fortran compiler. My question is why was this practice discontinued?

      It seems rather pointless to provide and distribute a free library that forces you to use a 3rd party commercial compiler (therefor with no benefit to you/AMD/the library developer) only to be able to link statically with the library (because the ACML library needs functions from the Fortran compiler's runtime lib)...

      Is there any chance that 32bit and 64bit builds with free tools will be included in the official releases again?

       

      2.

      While here I'd also like to request that builds that link both statically and dynamically to the CRT be available (otherwise you force users to a specific linkage strategy that might not suit their needs).

       

      3.

      It would also be welcome if you could provide (Windows) static libs that are built with "link time code generation" (the /GL and /LTCG switches in MSVC) so as to provide more efficient (most notably in terms of final binary size) final binaries.

      Connected to the "space efficiency" issue is the usage of the CRT: looking at the distributed libs one can see that they mention (for example) many functions from the printf family. I suppose that those are from debugging code that was not properly removed from release builds and are probably completely useless/pointless in a math library (used in a GUI environment). If I am correct in this assumption then it would also be welcomed if such "useless code" be removed from release builds

        • (32bit static) Windows builds with a free Fortran compiler&co.
          mickpont
          1) I did an experiment with the ifort32 build of ACML 4.3.0. I was able
          to successfully use the g77 compiler that comes with cygwin (GCC 3.4.4)
          to link with libacml_dll.lib by using these switches:

          g77 -fno-underscoring -fcase-upper main.f libacml_dll.lib

          Then the program runs successfully assuming that libacml_dll.dll
          is somewhere in your PATH. I modified the GNUmakefile in the
          example programs directory and all the programs ran fine, except
          that the acmlinfo example did not produce any output (it didn't
          crash or anything - just didn't display what it should). I think
          that's because of the different i/o systems coming into play
          when you use g77.

          Linking to the static library libacml.lib did NOT work - hundreds of
          link time error messages which I didn't try to fathom.

          (2) There are -MD and -MT builds for ifort under win64, but that's never
          been done for the 32-bit builds. They could no doubt be done, but
          32-bit implementations are in general a much lower priority for ACML.

          (3) I've not heard of the /GL and /LTCG switches before and my copy
          of Microsoft C doesn't seem to recognise them.

          The sprintf function gets used by the function ACMLINFO which
          outputs a description of the version of ACML. It also gets used by
          one or two another internal (non-documented) routines. Obviously
          in a GUI environment one would not wish to call ACMLINFO.

          Mick

            • (32bit static) Windows builds with a free Fortran compiler&co.
              domagoj.saric

               

              Originally posted by: mickpont

              1) I did an experiment with the ifort32 build of ACML 4.3.0. I was able to successfully use the g77 compiler that comes with cygwin (GCC 3.4.4) to link with libacml_dll.lib by using these switches: g77 -fno-underscoring -fcase-upper main.f libacml_dll.lib Then the program runs successfully assuming that libacml_dll.dll is somewhere in your PATH. I modified the GNUmakefile in the example programs directory and all the programs ran fine, except that the acmlinfo example did not produce any output (it didn't crash or anything - just didn't display what it should). I think that's because of the different i/o systems coming into play when you use g77. Linking to the static library libacml.lib did NOT work - hundreds of link time error messages which I didn't try to fathom.
               
              that's because static linking requires linking with fortran and c
              runtime libraries...
              ...and to have the static fortran libraries one ofcourse has to
              have the fortran compiler with which the library was built and
              that leads to the, current, paradoxical situation where you
              have to _pay_ for a compiler (that you will never use) only to
              be able to use/link with a _free_ library...
              ...can anyone officially say what is amd's stance on this? will
              there be 'really' free windows builds of acml in the future?
               
              also, linking the acml version 3.6.0 statically (the g77 win32
              build) gives of numerous msvc linker 4049 warnings [from
              the gnu fortran and c runtime .libs (yes i used the latest
              ones) required by the acml .lib]...the binary runs fine but still,
              warnings are always ugly and unwanted...
              ofcourse, if people would stop using dead languages (like
              fortran) things would be a lot simpler...  
               
              dynamic linking is not an option when your own binary is
              less than a megabyte and acml dlls total 12 megabytes,
              and you only use two functions from it (forward and
              inverse single precision 1D fft)...static linking brings in
              about 200kB of code...which one could still say is too
              much for two of the simplest fft functions...but that is
              bareable...
              Originally posted by: mickpont
              (2) There are -MD and -MT builds for ifort under win64, but that's never been done for the 32-bit builds. They could no doubt be done, but 32-bit implementations are in general a much lower priority for ACML.
               
              then, i'm afraid, that smells of (very) bad internal organization and
              build system design...
              ...if you use a proper cross platform build system (like boost build
              or cmake) there is almost no difference/additional amount of
              (human) work to build the target in one more configuration/'build
              variant'...provided that the build system supports it and has been
              setup for it ('once and for all')...
              besides that, the idea to 'semi-abandon' the 32 bit platform does
              not seem justified in view of the news that microsoft will release
              32 bit builds of windows 7...making that platform, unfortunately,
              last for another, probably, ten years...
              Originally posted by: mickpont
              (3) I've not heard of the /GL and /LTCG switches before and my copy of Microsoft C doesn't seem to recognise them.

              actually /gl is the compiler switch and /ltcg the linker switch for link time code generation...they've been added since visual studio 2005/msvc 8.0...i'd suggest an upgrade, its worth it its free actually (the express versions)...

              those switches will make the .lib itself a lot bigger but the final binary more optimal (which is logical actually when you think what it does)...although it does complicate things because .libs created that way are not compatible between different compiler versions (sometimes service packs)...but using a proper buidls system that builds everything in all possible variants automatically would make that a less of a complication...

               

               

              Originally posted by: mickpont

              The sprintf function gets used by the function ACMLINFO which
              outputs a description of the version of ACML. It also gets used by
              one or two another internal (non-documented) routines. Obviously
              in a GUI environment one would not wish to call ACMLINFO.



              sprintf is not the only one, there are also, for example, printf and fprintf which obviously write to 'files'...unfortunately i didn't have the time to make a simple test 'emtpy'/'hello world' project and link with the acml to see if those printf functions will be linked in even if no debugging/error handling acml functions are used...but still, if you have access to the sources you could take a look and make sure that no debug code 'leaked' into release builds...

                • (32bit static) Windows builds with a free Fortran compiler&co.

                  You are absolutely correct that static linking of ACML requires having the FORTRAN compiler with which it was built.

                  However, I'm puzzled by your comment:

                   "dynamic linking is not an option when your own binary is

                  less than a megabyte and acml dlls total 12 megabytes,"

                  Can you explain further why this is impossible?

                   

                    • (32bit static) Windows builds with a free Fortran compiler&co.
                      domagoj.saric

                       

                      Originally posted by: jim.conyngham@amd.com You are absolutely correct that static linking of ACML requires having the FORTRAN compiler with which it was built.

                      can you please then tell 'us' (the answer to my central question, and perhaps the others i also raised)...will amd provide "really free" win32&64 builds of acml?

                       

                       

                      Originally posted by: jim.conyngham@amd.com

                      However, I'm puzzled by your comment:

                       "dynamic linking is not an option when your own binary is

                      less than a megabyte and acml dlls total 12 megabytes,"

                      Can you explain further why this is impossible?

                       

                       

                      i did not say it is impossible, i said 'it is not an option'...when you are space-efficiency and/or distribution size conscious then bundling a whole library (of which you use like 1%) that is, alone, 10+ times bigger than your own binary...'is not an option'...

                       

                      along with that, the usual two arguments apply:

                      - tugging .dlls along with your exe/binary (in such 'unshared' manner, like in the same folder) is oxymoronic...that's what static .libs and static linking are for...

                      - sometimes dynamic linking/multiple dll's is simply not an option or just complicates things (like for instance in the case of vst plugins)...