Installing ATLAS in a mixed cygwin/MinGW env

  • R. Clint Whaley

    R. Clint Whaley - 2009-10-19

    I have not yet looked into this, but some users have done so.  Please post your workarounds, fixes, and problems here, so I can examine them when I get a chance to scope this out.


  • Sébastien Kunz-Jacques

    This describes how to make a MinGW32 build of ATLAS 3.9.14 and 3.9.16, not dependent on pthreads (but multithreaded using windows threads)

    **tools used**

     (e.g. current, 4.4.1-tdm2), or the last official MinGW (4.4.0, installed by following the "manual installation" steps . With a TDM MinGW, you may have to add -lgcc to gfortran options otherwise link won't work properly.

    2) The CYGWIN shell with MinGW bin path  added in front of the PATH variable (build does not  work from MSYS for some obscure path reasons ; some of the binaries that ATLAS uses at various probe stages do not find required files with MSYS path  scheme), and with the gcc4 packages installed (gcc4, gcc4-core, gcc4-fortran).

    **path issues and cygwin mount points**

    A problem arises because cygwin and MinGW understand Windows paths differently. therefore a configure performed from cygwin won't work (at some point gcc will complain that it does not find some file in /cygdrive/… : this is expected, since mingw knows nothing about /cygdrive/…). There is a simple way to get around this : mount the ATLAS dir as the same path under cygwin and windows (ie /path1/path2/…/path_n in cygwin should correspond to c:\path1\…\path_n in native windows). Mount points of cygwin 1.5 are stored in the registry; here is a sample .reg file to mount c:\ATLAS as /ATLAS under cygwin.:

        Windows Registry Editor Version 5.00

    If one then builds ATLAS in /ATLAS, the path problems detailed above do not occur.

    **ATLAS patches**

    a) Modify tune/sysinfo/findNT.c according to the comment around line 64 (remove '00') to use winthreads instead of pthreads.

    b) Modify include/atlas_r1parse.h in order to disable the check


    around line 351, otherwise the assert is triggered some times.

    c) edit makes\Make.thr to remove 'l3pt' on line 11 to limit the production of object files dependent upon pthreads.

    patch file :

        -- include/atlas_r1parse.h Wed Aug 19 16:08:54 2009
        +++ include/atlas_r1parse.h Sat Oct 17 15:24:48 2009
        @@ -348,7 +348,7 @@
               fpout = stderr;
               fpout = fopen(file, "w");
        -   assert(fpout);
        +   //assert(fpout);
            PrintR1Nodes(fpout, nq);
            if (fpout != stdout && fpout != stderr)
        -- makes/Make.thr Wed Aug 19 16:08:55 2009
        +++ makes/Make.thr Sat Oct 17 17:21:25 2009
        @@ -8,7 +8,7 @@
         all : lib
        -lib : lib.grd l3thr l3pt
        +lib : lib.grd l3thr
         slib3 : lib.grd $(sextthr)
         cd blas/level3 ; $(MAKE) slib
         cd $(GMMdir) ; $(MAKE) stlib
        -- tune/sysinfo/findNT.c Wed Aug 19 16:09:37 2009
        +++ tune/sysinfo/findNT.c Sat Oct 17 15:05:56 2009
        @@ -66,7 +66,7 @@
            fprintf(fpout, "/* Get rid of 00 if you don't want to build pthreads */\n");
        -      "   #ifndef ATL_WINTHREADS00\n      #include \"pthread.h\"\n   #endif\n");
        +      "   #ifndef ATL_WINTHREADS\n      #include \"pthread.h\"\n   #endif\n");
            #if ATL_NCPU != 0
               fprintf(fpout, "   #define ATL_NTHREADS %d\n", ATL_NCPU);
               for (i=0; (1<<i) < ATL_NCPU; i++);


    cygwin GCC must be used for some code outside the final lib (obscure path
    problems again?). configure must be passed the options

        -cc=/usr/bin/gcc-4 -C xc /usr/bin/gcc-4

    (regular 3.x gcc would probably also work here).

    complete configure command:

        export FREQ=2333
        export OPTS="-march=native -fno-common -mpreferred-stack-boundary=2"
        ../configure  -b 32 -m "$FREQ" -D c -DWALL -D c -DPentiumCPS="$FREQ" -with-netlib-lapack-tarfile=../lapack-3.2.1.tgz -Si latune 0 -cc=/usr/bin/gcc-4 -C xc /usr/bin/gcc-4 -shared -Fa ic "$OPTS" -Fa sk "$OPTS" -Fa dk "$OPTS" -Fa sm "$OPTS" -Fa dm "$OPTS" -Fa if "$OPTS"

    for MinGW TDM, one must add to configure

        -Fa if -lgcc

    performance is as follows (processor is a Core2 E6550):

                          single precision                  double precision
                    ********************************   *******************************
                          real           complex           real           complex
                    ----------  ----------  ----------  ----------
        Benchmark   Refrenc Present  Refrenc Present  Refrenc Present  Refrenc Present
        =========   ======= =======  ======= =======  ======= =======  ======= =======
          kSelMM      567.0   535.3    527.5   497.7    334.0   331.8    321.0   308.9
          kGenMM      162.8   119.4    164.5   164.5    155.5   145.8    154.4   146.7
          kMM_NT      135.8   153.8    132.7   158.7    104.6   138.4    115.7   146.2
          kMM_TN      159.6   157.8    123.4   120.1    123.3    99.8    127.1   101.3
          BIG_MM      553.1   539.1    554.4   547.0    322.1   318.8    324.2   318.4
           kMV_N       69.0    68.1    212.3   221.1     54.4    63.3     69.8    93.6
           kMV_T       87.5    86.4     91.5    91.7     49.9    45.7     74.1    71.1
            kGER       90.1    51.8    117.4   131.5     28.1    30.8     42.2    65.2

    so that the optimized kernels are indeed turned on.


    a) after build, make shared does not work as is

    b) the final lib may still have some dependencies to pthreads

    I already opened a ticket for a) - the problem is that make shared uses -lc
    which refers to a library libc that does not exist with MinGW. Exact error message is:

        >make shared
        cd lib ; make shared_all
        make: Entering directory `/programmes/ATLAS/build-mingw-4.4.0/lib'
        make dlls
        make: Entering directory `/programmes/ATLAS/build-mingw-4.4.0/lib'
        ld -mi386pe -shared -soname /usr/local/atlas/lib/libatlas.dll \
                  -o libatlas.dll -rpath-link /usr/local/atlas/lib \
                  -whole-archive libatlas.a -no-whole-archive -lc -lpthread -lkernel32 -lm
        c:\programmes\MinGW\bin\ld.exe: cannot find -lc

    A better way is to let gcc figure out the needed libraries, with commands such as

        gcc -shared -o libatlas.dll -Wl,-whole-archive libatlas.a -Wl,-no-whole-archive -Wl,-out-implib,libatlas_gcc.lib

    Although this may fail also because of b), with error messages such as

        >gcc -shared -o libatlas.dll -Wl,-whole-archive libatlas.a -Wl,-no-whole-archive -Wl,-out-implib,libatlas_gcc.lib
        Creating library file: libatlas_gcc.liblibatlas.a(ATL_init_node.o):ATL_init_node.c:(.text+0x2a): undefined reference to `_imp__pthread_mutex_init'
        libatlas.a(ATL_init_node.o):ATL_init_node.c:(.text+0x46): undefined reference to `_imp__pthread_cond_init'
        libatlas.a(ATL_join_tree.o):ATL_join_tree.c:(.text+0x40): undefined reference to `_imp__pthread_join'
        libatlas.a(ATL_signal_tree.o):ATL_signal_tree.c:(.text+0x11): undefined reference to `_imp__pthread_mutex_lock'
        libatlas.a(ATL_signal_tree.o):ATL_signal_tree.c:(.text+0x28): undefined reference to `_imp__pthread_cond_signal'
        libatlas.a(ATL_signal_tree.o):ATL_signal_tree.c:(.text+0x35): undefined reference to `_imp__pthread_mutex_unlock'
        libatlas.a(ATL_thread_free.o):ATL_thread_free.c:(.text+0xc): undefined reference to `_imp__pthread_attr_destroy'
        libatlas.a(ATL_thread_init.o):ATL_thread_init.c:(.text+0xd): undefined reference to `_imp__pthread_attr_init'
        libatlas.a(ATL_thread_init.o):ATL_thread_init.c:(.text+0x22): undefined reference to `_imp__pthread_attr_setdetachstate'
        libatlas.a(ATL_thread_init.o):ATL_thread_init.c:(.text+0x6b): undefined reference to `_imp__pthread_attr_setscope'
        libatlas.a(ATL_thread_tree.o):ATL_thread_tree.c:(.text+0x14): undefined reference to `_imp__pthread_create'
        libatlas.a(ATL_wait_tree.o):ATL_wait_tree.c:(.text+0x1c): undefined reference to `_imp__pthread_mutex_lock'
        libatlas.a(ATL_wait_tree.o):ATL_wait_tree.c:(.text+0x2a): undefined reference to `_imp__pthread_cond_wait'
        libatlas.a(ATL_wait_tree.o):ATL_wait_tree.c:(.text+0x94): undefined reference to `_imp__pthread_mutex_unlock'
        libatlas.a(ATL_wait_tree.o):ATL_wait_tree.c:(.text+0xb3): undefined reference to `_imp__pthread_mutex_lock'
        libatlas.a(ATL_wait_tree.o):ATL_wait_tree.c:(.text+0xc1): undefined reference to `_imp__pthread_cond_wait'
        libatlas.a(ATL_wait_tree.o):ATL_wait_tree.c:(.text+0x12c): undefined reference to `_imp__pthread_mutex_unlock

    in that case, just remove the offending object files with the command

        ar d libatlas.a (object file names)


    once cygwin and MinGW are set up and the library is patched, the following script can be used to perform the whole build (caution - it may be buggy). It also generates MSVC import libraries (tested with 2008), so that the resulting dlls can be used from there. As explained in the comments, you have to adjust some paths at the beginning of the script and execute it in your ATLAS dir. The build dir is created first.

        #the variables below need to be adjusted.
        #the ATLAS path must be the same in native windows and cygwin
        # c:\path_1\…\path_n <==> /path_1/…/path_n
        #can be gfortran_s if your gcc has it
        #MinGW gcc 4.4.0 has a dynamic libgfortran by default
        #(hence the gfortran dll will be needed at runtime anyway)
        export PATH="$CYGWIN_MSVC_PATH/VC/bin:$PATH"
        export PATH="$CYGWIN_MSVC_PATH/Common7/IDE/:$PATH"
        export PATH="$CYGWIN_MINGW_PATH/bin/:$PATH"
        rm -rf *
        OPTS="-march=native -fno-common -mpreferred-stack-boundary=2"
        ../configure  -b 32 -m "$FREQ" -D c -DWALL -D c -DPentiumCPS="$FREQ" -with-netlib-lapack-tarfile=../lapack-3.2.1.tgz -Si latune 0 -cc=/usr/bin/gcc-4 -C xc /usr/bin/gcc-4 -shared -Fa ic "$OPTS" -Fa sk "$OPTS" -Fa dk "$OPTS" -Fa sm "$OPTS" -Fa dm "$OPTS" -Fa if "$OPTS"
        make time
        make check
        make ptcheck
        for i in $(ls *.def); do
        lib /MACHINE:x86 /def:"$i"
        cd "${FULL_BUILD_PATH}/lib"
        # standalone dlls with static libgcc
        # the resultings dlls have no external dependencies.
        # historically, this was mandatory for code multithreaded with pthreads and linked against a
        # static gcc runtime lib: with a static link to libgcc, threads cannot be spread across several dlls.
        # For instance, liblapack_atlas.dll is non-threaded, and contains, atlas, cblas, f77blas and lapack.
        #gcc -shared -o libatlas_static.dll -Wl,-whole-archive libatlas.a -Wl,-no-whole-archive -Wl,-output-def,libatlas.def,-out-implib,libatlas_gcc_static.lib
        #gcc -shared -o libf77blas_atlas_static.dll -Wl,-whole-archive libf77blas.a -Wl,-no-whole-archive libatlas.a -lgfortran -Wl,-output-def,libf77blas_atlas.def,-out-implib,libf77blas_atlas_gcc_static.lib
        #gcc -shared -o libcblas_atlas_static.dll -Wl,-whole-archive libcblas.a -Wl,-no-whole-archive libatlas.a  -Wl,-output-def,libcblas_atlas.def,-out-implib,libcblas_atlas_gcc_static.lib
        #gcc -shared -o liblapack_atlas_static.dll -Wl,-whole-archive liblapack.a libf77blas.a libcblas.a -Wl,-no-whole-archive libatlas.a -lgfortran -Wl,-output-def,liblapack_atlas.def,-out-implib,liblapack_atlas_gcc_static.lib
        #gcc -shared -o libptf77blas_atlas_static.dll -Wl,-whole-archive libptf77blas.a -Wl,-no-whole-archive libatlas.a -lgfortran -Wl,-output-def,libptf77blas_atlas.def,-out-implib,libptf77blas_atlas_gcc_static.lib
        #gcc -shared -o libptcblas_atlas_static.dll -Wl,-whole-archive libptcblas.a -Wl,-no-whole-archive libatlas.a -Wl,-output-def,libptcblas_atlas.def,-out-implib,libptcblas_atlas_gcc_static.lib
        #gcc -shared -o libptlapack_atlas_static.dll -Wl,-whole-archive liblapack.a libptf77blas.a libptcblas.a -Wl,-no-whole-archive libatlas.a -lgfortran  -Wl,-output-def,libptlapack_atlas.def,-out-implib,libptlapack_atlas_gcc_static.lib
        #dlls linked against dynamic libgcc_s. here each dll contains only the code of the corresponding static lib.
        #needs a modified gcc 4.3 (that has ligcc_s) or gcc 4.4
        #To link against the dynamic libgfortran, replace -lgfortran by -lgfortran_s. Most probably not needed for threaded code.
        mkdir -p dynamic_libgcc
        cd dynamic_libgcc && rm -rf *
        cp ../*.a .
        gcc -shared -shared-libgcc -o libatlas.dll -Wl,-whole-archive libatlas.a -Wl,-no-whole-archive  -Wl,-output-def,libatlas.def -Wl,-out-implib,libatlas_gcc.lib
        gcc -shared -shared-libgcc -o libptcblas.dll -Wl,-whole-archive libptcblas.a -Wl,-no-whole-archive libatlas_gcc.lib  -Wl,-output-def,libptcblas.def,-out-implib,libptcblas_gcc.lib
        gcc -shared -shared-libgcc -o libptf77blas.dll -Wl,-whole-archive libptf77blas.a -Wl,-no-whole-archive libatlas_gcc.lib -l${FORTRAN_LIB}  -Wl,-output-def,libptf77blas.def,-out-implib,libptf77blas_gcc.lib
        gcc -shared -shared-libgcc -o libptlapack.dll -Wl,-whole-archive liblapack.a -Wl,-no-whole-archive libptcblas_gcc.lib libptf77blas_gcc.lib libatlas_gcc.lib -l${FORTRAN_LIB} -Wl,-output-def,libptlapack.def,-out-implib,libptlapack_gcc.lib
        gcc -shared -shared-libgcc -o libcblas.dll -Wl,-whole-archive libcblas.a -Wl,-no-whole-archive libatlas_gcc.lib  -Wl,-output-def,libcblas.def,-out-implib,libcblas_gcc.lib
        gcc -shared -shared-libgcc -o libf77blas.dll -Wl,-whole-archive libf77blas.a -Wl,-no-whole-archive libatlas_gcc.lib -l${FORTRAN_LIB}  -Wl,-output-def,libf77blas.def,-out-implib,libf77blas_gcc.lib
        gcc -shared -shared-libgcc -o liblapack.dll -Wl,-whole-archive liblapack.a -Wl,-no-whole-archive libcblas_gcc.lib libf77blas_gcc.lib libatlas_gcc.lib  -l${FORTRAN_LIB} -Wl,-output-def,liblapack.def,-out-implib,liblapack_gcc.lib
        rm *.a
        cd "${FULL_BUILD_PATH}/lib"
            mkdir -p static_libgcc
        cd static_libgcc && rm -rf *
        cp ../*.a .
        #separate dlls with static libgcc. works also in the threaded case starting with ATLAS 3.9.5 provided win32 threads are used.
        gcc -shared                -o libatlas.dll -Wl,-whole-archive libatlas.a -Wl,-no-whole-archive -Wl,-output-def,libatlas.def -Wl,-out-implib,libatlas_gcc.lib
        gcc -shared                -o libptcblas.dll -Wl,-whole-archive libptcblas.a -Wl,-no-whole-archive libatlas_gcc.lib  -Wl,-output-def,libptcblas.def,-out-implib,libptcblas_gcc.lib
        gcc -shared                -o libptf77blas.dll -Wl,-whole-archive libptf77blas.a -Wl,-no-whole-archive libatlas_gcc.lib -lgfortran  -Wl,-output-def,libptf77blas.def,-out-implib,libptf77blas_gcc.lib
        gcc -shared                -o libptlapack.dll -Wl,-whole-archive liblapack.a -Wl,-no-whole-archive libptcblas_gcc.lib libptf77blas_gcc.lib libatlas_gcc.lib  -lgfortran -Wl,-output-def,libptlapack.def,-out-implib,libptlapack_gcc.lib
        gcc -shared                -o libcblas.dll -Wl,-whole-archive libcblas.a -Wl,-no-whole-archive libatlas_gcc.lib  -Wl,-output-def,libcblas.def,-out-implib,libcblas_gcc.lib
        gcc -shared                -o libf77blas.dll -Wl,-whole-archive libf77blas.a -Wl,-no-whole-archive libatlas_gcc.lib -lgfortran -Wl,-output-def,libf77blas.def,-out-implib,libf77blas_gcc.lib
        gcc -shared                -o liblapack.dll -Wl,-whole-archive liblapack.a -Wl,-no-whole-archive libcblas_gcc.lib libf77blas_gcc.lib libatlas_gcc.lib  -lgfortran -Wl,-output-def,liblapack.def,-out-implib,liblapack_gcc.lib
        rm *.a
        cd "${FULL_BUILD_PATH}/lib"
        cd ${CYGWIN_ATLAS_PATH}
        mkdir -p "build-$BUILD_SUFFIX"
        cd "build-$BUILD_SUFFIX"
        if ; then
          echo "did not manage to go into the build dir"
          exit 1
        cd "$FULL_BUILD_PATH/lib"
        cp libatlas.a libatlas.a.bak
        ar d libatlas.a ATL_{s,d,c,z}pt{gescal,geadd,trscal,hescal,gezero}.o


  • Sébastien Kunz-Jacques

    Note: the above performance figures are for 3.9.14.

    3.9.15 has bugs which prevent the build to work.

    With exactly the same setup for 3.9.16, the build works also - although something crashed along the way (the first execution of  "./xmmksearch_sse -p d", I believe). make time/check/ptcheck works, and times are marginally better for kSelMM:

                            single precision                  double precision
                    ********************************   *******************************
                          real           complex           real           complex
                    ----------  ----------  ----------  ----------
        Benchmark   Refrenc Present  Refrenc Present  Refrenc Present  Refrenc Present
        =========   ======= =======  ======= =======  ======= =======  ======= =======
          kSelMM      567.0   561.4    527.5   525.0    334.0   332.7    321.0   319.9
          kGenMM      162.8   119.7    164.5   163.7    155.5   146.4    154.4   146.0
          kMM_NT      135.8   153.1    132.7   158.0    104.6   141.0    115.7   145.6
          kMM_TN      159.6   157.4    123.4   120.8    123.3    99.9    127.1   102.1
          BIG_MM      553.1   540.6    554.4   545.4    322.1   318.5    324.2   318.1
           kMV_N       69.0    69.1    212.3   225.5     54.4    65.8     69.8    95.1
           kMV_T       87.5    88.1     91.5    92.0     49.9    49.6     74.1    72.6
            kGER       90.1    52.2    117.4   132.6     28.1    31.5     42.2    66.8

  • Paul Tuinenga

    Paul Tuinenga - 2010-01-20

    Agreed, this is simply cross-compiling from Cygwin to Msys (i.e. from Windows to Windows).  Can have more install flexibility by using symbolic links, which Cygwin has, for example:
        cd /
        ln -s /cygdrive/c/msys msys
        ln -s /cygdrive/c/mingw mingw

    then (as above post) add the relevant MinGW stuff ahead of the Cygwin path:
        export PATH=/mingw/libexec/gcc/mingw32/4.4.0:/mingw/bin:$PATH

    then replace strong (') quotes with weak (") quotes where commands are issued in CONFIG/src/config.c, except where unneeded for with calling make.

        do use configure option -C xc /bin/gcc for the Cygwin-based helper codes
        NO need for nocygwin flag, it's not in MinGW gcc anyhow
        add '\r' to the characters checked in FixString (tune/sysinfo/emit_buildinfo.c), this is harmless for other ports
        misc. alternate ways of doing the same things, e.g. RunBigMM (CONFIG/src/atlbench.c):
            sprintf(cmnd, "cd bin ; make x%cmmtst_big", pre);
            sprintf(cmnd, "cd bin && make x%cmmtst_big", pre);
                also harmless for other ports

    Then ATLAS install pretty much runs as advertised. Did this on Windows 7 (x64).

  • Sébastien Kunz-Jacques

    p2nenga, could you elaborate (or give a patch) on the way you edited config.c ?

    I now have a cygwin install on a disk different than the windows install disk, and the technique I described above does not work anymore.

  • Paul Tuinenga

    Paul Tuinenga - 2010-02-08

    (CONFIG/src/config.c) replace all instances of ' (strong quote) with " (weak quote) in strings used as shell commands except those issued for “make” which is resistant to this parsing issue

    (tune/sysinfo/emit_buildinfo.c) '\r' to the characters checked in FixString (*nix systems won't care)

    (CONFIG/src/atlbench.c) in RunBigMMchange
    sprintf(cmnd, "cd bin ; make x%cmmtst_big", pre);
    sprintf(cmnd, "cd bin && make x%cmmtst_big", pre);
    sprintf(cmnd, "./bin/x%cmmtst_big -n %d -Test 0 > big.out\n", pre, n);
    sprintf(cmnd, "cd bin && x%cmmtst_big -n %d -Test 0 > ../big.out", pre, n);

    again, *nix systems won't care though these are lame hacks

    (everywhere) replace instances of /dev/nul with nul

    Have also generated Msys libs for PETSc, SuperLU, and UMFPACK by having cygwin "run" the MinGW tools.  Some time later, I expect to run MSVC … if you get there first, I'd appreciate any hints.

  • Sébastien Kunz-Jacques

    thanks ! I will try that. Regarding MSVC, that's what I used to do some time ago (use cl as the interface compiler), but this was a eral pain and had a tendency to break at each new version of ATLAS… Hence now I build dlls with gcc, and import libs with the MSVC tool LIB, and use these from MSVC (as explained above). This avoids messing with cl during the ATLAS compilation stage (and the gcc-to-cl command line translator included with ATLAS is broken anyway; I had to rewrite one - in python - to make that approach work). If you are interested, I can find the notes I had on cl / gcc interaction in ATLAS, but they will probably need some update to make them work again.

    Btw, when I compile ATLAS 3.9.22 under MinGW, it does not pass 'make check' or 'make ptcheck' (some exes segfault). Did you encounter the same issue ?

  • David ROY

    David ROY - 2011-01-07


    First of all thanks for sharing your experience on compiling ATLAS for Windows. This is very useful and very valuable.

    I'm trying to compile Python's Scipy package in debug version for a complete MSVC debug workflow including using python debug (/MDd) dll. Thus I need first to compile ATLAS with MSVC in order to be able to compile Scipy.

    I tried and failed with a Cygwin  + MSVC pipeline. However I do like kunzjacq2 pipeline Cygwin + MinGW -> .dll -> .def ->.lib because I did successfully used it in the past to compile zlib on Windows. I could then successfully link with a MSVC project.

    Thanks to kunzjacq2 very detailed explanations, I managed to configure and build version 9.14
    I had some issues I'd like to share with you:

    - I'm on a Corei7 architecture: during the configure step, it searched for ARCHS/Corei732SSE3.tgz that doesn't exist (there's only Corei764SSE3.tgz). Is that because I used option -b 32? I have no other choice since x64 compilation is not implemented, and moreover I need x86 libraries…

    - Though the INSTALL successfully terminated, I had some errors during make build and I don't know if they were insignificant or if the resulting libraries are rotten:
    cmm_b1.c:81:5: error: #error "This kernel requires x86-64 assembly!"
    cmm_b1.c:96:5: error: #error "Max KB is 80!"
    cmm_b1.c:185: Error: bad register name `%rbp'
    + lots of other errors in cmm_b1.c
    FlagCheck.c:1:0: error: bad value (ultrasparc) for -mtune= switch
    cc1.exe: error: unrecognized command line option "-mips4"
    ld -mi386pe -shared -soname /usr/local/atlas/lib/libatlas.dll \
               -o libatlas.dll -rpath-link /usr/local/atlas/lib \
               -whole-archive libatlas.a -no-whole-archive -lc -lpthread -lkernel32 -lm
    C:\MinGW\bin\ld.exe: cannot find -lc
    -> kunzjacq2 said that make shared would fail, so maybe it's related
    gfortran -O -lgcc -m32 -o xsinvtrsm sinvtrsm.o ATL_strsm.o \
                       /ATLAS/build-mingw/lib/libtstatlas.a /ATLAS/build-mingw/lib/liblapack.a /ATLAS/build-mingw/lib/libcblas.a /ATLAS/build-mingw/lib/libatlas.a -lpthread -lkernel32 -lm
    sinvtrsm.o:invtrsm.c:(.text+0x50): multiple definition of `__main'
    c:/mingw/bin/../lib/gcc/mingw32/4.5.0/libgcc.a(__main.o):(.text+0x7c): first defined here
    collect2: ld returned 1 exit status
    zmm_b1.c:153:22: error: 'cwrdKB' undeclared (first use in this function)

    I tried "make time" and "make check" but both fail with the same kind of errors:

    gfortran -O -lgcc -m32 -o xsinvtst sinvtst.o \
                       /ATLAS/build-mingw/lib/libtstatlas.a /ATLAS/build-mingw/lib/l
    iblapack.a /ATLAS/build-mingw/lib/libcblas.a /ATLAS/build-mingw/lib/libf77blas.a
                       /ATLAS/build-mingw/lib/libatlas.a -lpthread -lkernel32 -lm
    sinvtst.o:invtst.c:(.text+0x660): multiple definition of `__main'
    c:/mingw/bin/../lib/gcc/mingw32/4.5.0/libgcc.a(__main.o):(.text+0x7c): first defined here
    collect2: ld returned 1 exit status

    I don't know yet if the resulting libraries are usable or not, I need to try.
    Thanks again for all your efforts, and I hope that my experience can help in improving compilation on Windows.


  • R. Clint Whaley

    R. Clint Whaley - 2011-07-01


    I think the 3.9.44 can now use the cygwin compilers w/o changing the registry.  I build wrappers around the functions that handle the path mangling.  However, I currently only have this setup for the 64-bit install, because I now have ATLAS using Windows threads with the cygwin gcc.

    Do you guys need MinGW even when Windows threads are used by normal gcc?  If so, I can probably modify the install to setup the same wrappers for 32 bits.

    Unfortunately, I'm about to have to start working mainly on non-ATLAS stuff, and neither 32 or 64 bits is working perfectly yet.  On my machine, the 32-bit install finishes the install, but actual applications are a seg-fault & wrong answer fest that hopefully is mostly linked to bad architectural defaults.

    If any of you have a chance to look at the 64 bit install, maybe you can understand what is going on.   For 64 bits, I got it so ATLAS can build most of the library, but the executables that link to it fail to do anything (no output, no error message).  If you put in flush(stderr) statements in the executables, then you get multiple copies of one-time messages, like the main routine is being invoked multiple times, with it dying each time it calls ATLAS.  My suspicion is that the problems are all library/dll related, where I'm getting 32-bit system libs dynamically linked to my 64-bit executable.

    Let me know if you figure something out. You can read the (64-bit) install instructions I've created so far in
    To get around earlier problems, I did my Fortran links with "-static". I suspect this shouldn't be necessary if you the libs are setup right, and it might be necessary to remove this option from the generated once you figure out how to get the right libs automatically.

  • Anonymous - 2013-07-17

    Great information !


Log in to post a comment.