working on 32-bit windows but not on 64-bit

2011-05-26
2013-06-06
  • Panagiotis Vouzis

    I have successfully used mingw to build a 32-bit dll, a static
    library, and to link the two together on CentOS. The final package
    works as expected on my 64-bit Windows 7 laptop under cygwin and
    msdos.

    I managed to do exactly the same for the 64-bit version. However, when
    I try to execute the same on my laptop I get "The application was
    unable to start correctly (0xc0000022). Click OK to close the
    application." I get this when I double click on it or when I try to
    run it under DOS. Under cygwin it just crashes quietly.

    Although I am able to debug the 32-bit version under cygwin,  I cannot
    debug the 64-bit version.  gdb doesn't recognize the format. nm and
    objdump say "File format not recognized" There must be something wrong
    either during the compilation or linking. On the other had I have
    tried small 64-bit "Hello World" examples and they work fine.

    I  tried to use Visual Studio debugger, but again it crashes before I
    try to run it.

    My biggest problem is that I don't know how to approach the problem.
    Do you have any suggestions?

    Thanks

    P.S. For the 64-bit compilation I use
    /opt/mingw64/cross_win64/bin/x86_64-w64-mingw32-gcc which looks a bit
    weird that it has that "mingw32" at the end. I think is the correct
    compiler though.

     
  • rubenvb

    rubenvb - 2011-05-26

    Where did you find the compiler? From the mingw-w64 site or from the CentOS repository?

     
  • Panagiotis Vouzis

    From http://www.mingw.org/

    I forgot to mention that I managed to build a static version of the code and run it successfully on 64-bit Windows 7.

     
  • rubenvb

    rubenvb - 2011-05-26

    Mingw.org does not have a x86_64-w64-mingw32 compiler. (the last 32 comes from win32, which is the API  common to x86 and x64 Windows). A link or reference to the page you found it would help a lot.

    By the way, did you by chance forget to copy libgcc_s_sjlj-1.dll to the directory of the executable?

     
  • Panagiotis Vouzis

    I didn't install it on the computer so I am not 100% sure what is the source. In any case, since I have the  x86_64-w64-mingw32 it means that I should be able to build 64-bit Windows applications. Right? Do you think the source of the compiler would make a difference? I could find out if it will give you a clue.

    I didn't have  libgcc_s_sjlj-1.dll copied in the executable's path, but even after I did, nothing changed. Is this 100% necessary? I believe if it would need it, I would get a pop up window asking specifically for this dll. The problem is that it crashes before any window pops up.

    Thanks a lot.

     
  • rubenvb

    rubenvb - 2011-05-26

    Yes, the "x86_64" means 64-bit windows, the "w64" means it is built with/for mingw-w64 (this project) and the mingw32 is GCC's Windows (desktop) target.

    The missing DLL would not pop up a nice error message. I've never had that happen (not with Visual Studio either). Did you try Dependency Walker (x64) on the executable? If all DLL's are found, there must be something wrong with the compiler/toolchain, in which case it will certainly help to know which file you downloaded.

    In the meantime, you could try the autobuilds, or sezero's Personal build. Both have Linux cross-compilers. Both can be found here: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-05-26

    The toolchain directory being /opt/mingw64/cross_win64 slightly suggests that it is one of my personal builds (sezero_…) However we have little information as to what you are doing.
    - Cygwin is 32 bit, you aren't supposed to run it with cygwin, let alone debug it using a 32 bit gdb.
    - You can't ever run a windows x64 application from msdos (don't know how you do that using your x86 versions)
    - Did you build your dll as x64 along with your exe? (Mismatched exe/dlls won't work.)
    - Is this C or C++? How do you compile your programs?

     
  • Panagiotis Vouzis

    Are you saying that if the specific libgcc_s_sjlj-1.dll is missing then you don't get a nice pop window? I am double checking, because usually when a dll is missing, Windows tells you which on is it (I still remember the dll hell).

    I had already used Dependency Walker and the only warning I got was the one with the yellow asterisk next to MSVCRT.DLL which means

    "Dynamic module. This module was detected during profiling and was dynamically loaded or used by its parent module. If the module has no parent, then Dependency Walker was unable to determine who loaded the module. See Using Application Profiling to Detect Dynamic Dependencies for more information."

    I also get some "RED" in the actual bases for some dlls.

    When I run it it crashes with the message:

    00:00:00.188: Second chance exception 0xC0000005 (Access Violation) occurred in "c:\cygwin\home\panos\documents\temp\BARON-WIN64.DLL" at address 0x000000006ACEAA80 by thread 1.
    00:02:45.720: Exited "c:\cygwin\home\panos\documents\temp\BAXWIN64.EXE" (process 0x15D8) with code -1073741819 (0xC0000005) by thread 1.

    I will try you suggestion to download a new compiler. Just to get it right: since I want to build a 64-bit Windows on 64-bit linux mingw-w64-bin_x86_64-linux_20110517.tar.bz2 would work.

    I appreciate your help. I haven't had any progress with this problem for more than a week now. I keep hitting a brick wall.

     
  • Panagiotis Vouzis

    sezero please see my responses below:

    - Cygwin is 32 bit, you aren't supposed to run it with cygwin, let alone debug it using a 32 bit gdb.
    I didn't know that. Is there a 64-bit alternative. What about msys?

    - You can't ever run a windows x64 application from msdos (don't know how you do that using your x86 versions)
    I didn't know this either. However, even when I double click on it it crashes. I get "baxwin64.exe has stopped working"

    HOWEVER, when I try to run the static windows 64-bit version under cygwin and msdos it runs just fine. Dependency Walker says it is x64 applications.

    - Did you build your dll as x64 along with your exe? (Mismatched exe/dlls won't work.)

    I build both as x64. I double checked with Dependency Walker and they show up as x64.

    - Is this C or C++? How do you compile your programs?

    It is C and fortran. I compile and link everything by using the x64 bit mingw too chain. I have successfully build 32- and 64-bit static and dynamic versions on linux.

    As a side note: something that I suspect might be causing my problems are a few callbacks from the dll to a static library. However, this works fine on 32bit and on 64-bit and 32-bit Linux.

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-05-27

    > - Cygwin is 32 bit, you aren't supposed to run it with cygwin,
    > let alone debug it using a 32 bit gdb.
    > I didn't know that. Is there a 64-bit alternative. What about
    > msys?

    No. MSYS is 32 bit too, no native 64 bit version

    > - You can't ever run a windows x64 application from msdos
    > (don't know how you do that using your x86 versions)
    > I didn't know this either. However, even when I double click
    > on it it crashes. I get "baxwin64.exe has stopped working"

    I suppose you are referring to the windows cmd.exe console
    as 'dos', which isn't dos, but whatever

    > - Is this C or C++? How do you compile your programs?
    >
    > It is C and fortran. I compile and link everything by using
    > the x64 bit mingw too chain. I have successfully build 32-
    > and 64-bit static and dynamic versions on linux.

    Hmm, OK, are you copying the 64 bit version of libgfortran-3.dll
    alongside your dynamic exe?  This may very well be the problem.

    Since you are cross-compiling on linux, you can find it using a
    shell command like:
    find /opt/cross_win64/ -name libgfortran-3.dll

    > sezero they are your versions. They were downloaded from this
    > page

    I see.  FWIW, my latest build is from 2011-05-10.

     
  • Panagiotis Vouzis

    Problem solved, and of course it was my fault!

    I was using "-Lpath/of64-bit/library -lname_of_library" to link to a 64-bit library. However, the name of the library wasn't "libname_of_library" but it was "name_of_library.dll". So, my guess is that the linker wasn't linking to that library, but was picking the 32-bit library for linking, which was in another directory. The linking would go through fine, but then it would crash when I was trying to run it.

    By the way I wanted to ask something else that I have noticed. When I link with the 32-bit mingw I can used .lib version of the 32-bit library, and it works file. However, when I use the 64-bit mingw and I try to link with the 64-bit .lib library it goes fine, but then it crashes when I run it. Does this make sense? If not, my libraries might be messed up!!

    You were right that cygwin is not able to debug 64-bit executables with gdb. However, this http://www.equation.com/servlet/equation.cmd?fa=gdb works really nice under cygwin and DOS (or whatever the Windows  cmd is). It doesn't have all the features of the linux gdb, but it does an very good job.

    Thanks again!

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-05-27

    > Problem solved,

    Good to hear that it is solved

    > file. However, when I use the 64-bit mingw and I try to link
    > with the 64-bit .lib library it goes fine, but then it crashes
    > when I run it. Does this make sense? If not, my libraries
    > might be messed up!!

    At present, MSVC-generated x64 *.lib files are not supported;
    Kai may have more to say about that.  If you must link to MSVC-
    generated x64 *.dll files, please use "gendef" tool to generate
    GNU-ld compatible lib*.a files and use them instead.

     

Log in to post a comment.