Hi I am using mingw w64 for compiling my windows service.
Everything was good until I wanted to compile for 32bit version.
I am missing libwintrust file.
Does anyone know more about this?
There is libwintrust in 64bit toolchain but not in 32 :(
You can try linking with the DLL itself. Doesn't always work, but it's worth a try. Something like:
gcc -o foo.exe obj1.o obj2.o c:/windows/syswow64/wintrust.dll
If that doesn't work you can try using the wintrust.lib file from the Windows SDK.
Ok, at the end it was not so hard.
I guess that direct linking wont work because gcc doesn't know the entry point for WinVerifyTrust#12 and in wintrust.dll name is without #12 (as I understand #12 is stack size for input data). Also Windows SDK have different compiler so it probably have different linker.
Solution is pretty simple. You can generate library for almost any dll with dlltool in bin folder of mingw w64(32bit and 64bit). All you need is def file. In def file you have to use it with suffix because mingw is asking for it. Also you have to use option (-k) because in wintrust.dll it is without #12 so dll tool will know what to look for.
Now everything works :)
Related
I'm making a 3D printer from scratch, hardware and software. I am using mingw to compile on windows and it works. But the .exe it produces relies on a bunch of .dlls in mingw's bin folder. So that means that either I'm doing something wrong or just don't know which .dlls need to go with my .exe.
The command I run to compile is:
g++ -o Slicer.exe "d:\Programming And Creativity\Slicer\main.cpp" "d:\Programming And Creativity\Slicer\slice.cpp" "d:\Programming And Creativity\Slicer\face.cpp" "d:\Programming And Creativity\Slicer\line.cpp" "d:\Programming And Creativity\Slicer\vertex.cpp"
If I try going to my project's folder and running g++ from there, it complains about a bunch of missing files. How can I reduce the numer of dll's needed to run the exe file?
I figured out a solution to my problem, I just had to add the --static flag.
I am trying to link glfw on windows.
On Linux it was fairly straight forward:
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps/glfw/build/src/libglfw3.a" platform="posix"
libs"Xi" "pthread" "X11" "Xxf86vm" "Xrandr" "pthread" "GL" "GLU" "Xinerama" "Xcursor" platform="posix"
If I try to link with a .dll on windows, dub tells me that Error: unrecognized file extension dll.
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps\\glfw\\build\\src\\Debug\\glfw3.dll" platform="windows"
If I try to link with a .lib, dub tells me that COFF is not supported.
dependency "derelict-glfw3" version="~>2.0.0"
subConfiguration "derelict-glfw3" "derelict-glfw3-static"
sourceFiles "deps\\glfw\\build\\src\\Debug\\glfw3.lib" platform="windows"
GLFW was built with vs2013. What do I have to do differently?
There's three cases here:
Default 32 bit Windows build. dmd on Windows, by default, builds 32 bits using the old OMF linker format. You cannot link straight to a dll and need a .lib. But since it uses the old format, most .libs provided won't work - you have to make your own.
(lol i want this in the list item but markdown sucks. whatever)
Download this thing to get implib.exe: http://ftp.digitalmars.com/bup.zip
and use that to make a .lib from the .dll: implib /s yourdll.lib yourdll.dll and try to link with the new lib. (Add it to the files list like you are already doing)
If it doesn't work, try the command again, but this time without the /s switch.
It should work by then.
-m32mscoff 32 bit builds. With that flag to dmd, it will output a 32 bit program using the new COFF format instead of the old omf format. For it to work, link.exe in your path MUST be the Microsoft linker, from Visual Studio, instead of the default Digital Mars optlink.exe (which, confusingly, was also called link.exe until recently. That was nice when it was a compatible replacement for the Microsoft one.... twenty years ago...).
Anyway, if you have the Microsoft C++ compiler and linker installed and put that link.exe in your path, dmd -m32mscoff should work using existing .lib files from the dlls.
TIP: If you used the Windows installer for dmd, open the "D2 64 bit command prompt" from the start menu to get the path set up. It will tell you to use -m64, but you can also use -m32mscoff from that environment and it should work. if everything installed properly.
-m64 64 bit builds. Basically the same as the mscoff switch - you need the Visual C++ linker in your path - but does 64 bit instead of 32. Of course, this requires a 64 bit dll and lib to be there too.
In the comments, it sounds like you might also be facing some bugs, I don't know about that, the above is if everything else is working properly.
I have a project written in gcc - bison -flex on Linux environment. All the project is implemented into a *.so file and is called from python-tkinter graphic surface.
There is a need to run it on windows. However I'd avoid to install all the windows equivalent of gcc - bison -flex programs.
Is it possible to force gcc IN LINUX ENVIRONMENT to compile WINDOWS DLL instead of *.so? It could make life easier to use the same technics as I do now: just do calls from python-tkinter graphic surface.
You can, of course, cross-compile it.
You'll need some packages installed, though.
Your normal project would be able to build if you use the MINGW equivalent of GCC for the target architecture.
Also, take a look at this:
Manual for cross-compiling a C++ application from Linux to Windows?
The linking can be kind of troublesome though, since it could come a time where softlinking fails due to versions. In that case you'll need to create some symbolic links to the correct version.
The output of the compilation process should be with -o DYNAMIC-LIBRARIE-NAME.dll and of course use the -shared flag.
Hope it gives you some pointers..
Regards.
I'm learning SDL through Lazy Foo's tutorial, but I can't proceed further as IMG_Load doesn't seem to work. I tried setting it up like he says, but it just doesn't work. I put all the include files into include folder, and all the lib files into the lib folder. What I found is that there were x86 and x64 folders in the lib folder. When I tried x64 (because I have a 64-bit system)it all worked fine, CodeBlocks even told me suggestions (like when I wrote "img" it showed up a suggestion "IMG_Load" (which means the library got initalized?)), but when I come to compiling my code, this happens: http://puu.sh/3Eqa5.png. When I try with the x86 version, exact same error.
I had a little search around the internet, and all I could find were a few threads, but most of them were abandoned. The closest I got to answering my problem was this: http://www.dreamincode.net/forums/topic/118299-sdl-image-error-sdl/ but the guy solved his problem by downloading a problem which Linux can use, not Windows.
}
I'm running Windows 7 64-bit, CodeBlocks 12.11, SDL 1.2.15 and SDL_Image 1.2.12.
I really don't know what the problem is!
You should go to the Compiler and Debugger settings again and under the Linker Settings tab paste:
-lSDL_image
In addition to the #Aleeee's answer, a command line solution is to add -lSDL2_image compiler flag (SDL2 is the up-to-date version by the time of this writing).
Compilation example:
gcc -o object_file_name source_file_name.c `sdl2-config --cflags --libs` -lSDL2_image
It turns out the SDL_Image library I was using was buggy. I don't know how that happened though. I just had to use a older version. Thanks to anyone who helped!
Under cygwin, with libtool I am trying to link a static library. the --mode=link cl.exe line invokes ar cru on the .obj files to create the .lib. However, I know there's another program under windows, LIB. As far as I understand, it's equivalent to ar, but will it make any difference in using ar+ranlib vs. LIB, and how can I force libtool to use LIB instead of ar?
Since setting AR and AR_FLAGS won't work, the only easy solution (that I haven't tried) is CCCL which wraps up cl.exe and link.exe for a neater interface to those programs for autoconf packages. It looks kind of old now, but it might work.
The installation instructions assume that CC/CXX are going to be cl.exe, but you're probably using GCC. In that case, probably AR=cccl needs to be an argument to configure.