I want to install the FFTW library in my system which is running on Windows 10. My compiler is minGW GCC 10.1 and I am using Code Blocks.
I have downloaded the 64-bit version fftw-3.3.5-dll64.zip from http://www.fftw.org/install/windows.html and then opened the command window as adminstrator and set my directory to the bin folder of the mingw64 so that I can run dlltool.
However, when I type the command dlltool -d libfftw3-3.def I am getting the error dlltool: Can't open def file: libfftw3-3.def
I guess this is happening because the libfftw3-3.def file is inside the FFTW folder and cannot be seen by the dlltool. Is that right? What should I do?
Actually the reason seems to be rather obvious. As I wrote in my question the files libfftw3-3.def, libfftw3f-3.def and libfftw3l-3.def are located inside the FFTW folder (wherever might that be in your case). I copied an pasted them inside the bin folder of the mingw64 compiler and then executed the following commands:
dlltool -d libfftw3-3.def
dlltool -l libfftw3-3.lib
Then repeated the process for the other two .def files.
Related
Context
As the title suggest, I am trying to compile all .c files in a specific directory.
I am aware from this post that in Linux environment, you can use globbing and do gcc -o executable *.c. However, I am trying to do exactly the same, on a Windows environment.
Question
How can I compile all .c files in a specific/current directory using Cygwin's gcc command on a Windows 10 environment.
Additional Notes
Operating System: Windows 10 (x64)
Runtime Environment: Cygwin
Edit #1
Per #matzeri's suggestion, I found out that globbing (*.c via the Cygwin termninal) works, however, I need to be able to do it via the terminal.
I want to distribute a gcc compiler within our company. I built required version from the sources, installed it in specified directory on my machine (all machines, btw, have the same architecture). I expected that I can put contents of this directory on the server and with the next update all my colleagues will get a new compiler.
But of course that doesn't work.
I tried to search for a ready solution for the linux but couldn't find anything.
Right now if I try to compile some basic program I get an error:
gcc: error trying to exec 'cc1plus': execvp: No such file or directory.
But this file was build and indeed resides in one of the subfolders of main install directory. I tried to explicitly specify the path to this subprogramm using GCC_EXEC_PREFIX and COMPILER_PATH environment variables but with no luck.
Is it possible to achieve what I want?
I cannot find a way to make Allegro5 work with FreeBasic on Windows.
I downloaded and installed FreeBASIC-1.05.0-win32.exe.
I downloaded Allegro binaries allegro-5.0.10-mingw-4.7.0.
The version of fbc installed is the standalone one.
I created allegrolibs folder and copied these libraries from the Allegro distribution to allegrolibs:
liballegro_5.0.10-md.a
liballegro_font-5.0.10-md.a
liballegro_ttf-5.0.10-md.a
I added the necessary allegro dlls from the Allegro distribution to examples/graphics/allegro:
allegro_font-5.0.10-md.dll
allegro_ttf-5.0.10-md.dll
allegro-5.0.10-md.dll
I run fbc from the command line, trying to compile hello.bas from examples/graphics/allegro5:
fbc -s gui -p allegrolibs examples/graphics/allegro5/hello.bas
The program compiled just fine.
However, at runtime hello.exe shows me this error:
The program can't start because libgcc_s_dw2_1.dll is missing from your computer.
Copy libgcc_s_dw2_1.dll from FreeBASIC\bin\win32 to the folder where hello.exe resides, then run:
The program can't start because libstdc++-6.dll is missing from your computer.
Add libstdc++-6.dll from a ming4.7.0 binary distribution then run:
The program can't start because libgcc_s_sjlj-1.dll is missing from your computer.
Add libgcc_s_sjlj-1.dll from ming4.7.0 binary distribution then run:
The program can't start because libwinpthread-1.dll is missing from your computer.
Add libwinpthread-1.dll from ming4.7.0 binary distribution then run:
The procedure entry point __gxx_personality_v0 could not be located
in the dynamic link library libstd++-6.dll.
At this point I'm stuck. What is it that I'm doing wrong? Anybody who tried the same and was able to solved it is willing to help with the issue?
allegro-5.0.10-mingw-4.7.0 binary for Windows was compiled with mingw-4.7.0 compiler.
freeBASIC was compiled with a mingw-w64 compiler.
But as far as dynamic linking, they can work together.
The binary package for Windows allegro-5.0.10-mingw-4.7.0 contains among many other things two files:
allegro-5.0.10-monolith-mt.dll
liballegro-5.0.10-monolith-mt.a
Either of them can be used to link Allegro 5 library to the exe:
Copy allegro-5.0.10-monolith-mt.dll or liballegro-5.0.10-monolith-mt.a in allegrolib folder.
Modify allegro.bi, allegro_font.bi, allegro_ttf.bi replacing line 35 with:
#inclib "allegro-5.0.10-monolith-mt"
Run from the console:
fbc -s gui -p allegrolib examples/graphics/allegro5/hello.bas
allegro-5.0.10-monolith-mt.dll needs to be placed in the same folder with hello.exe.
I am trying to use gopacket on my windows 10.
I'm using it to sniff and inject packets directly to/from the NIC.
I can easily compile and run my code with GOARCH=386 but can't in GOARCH=amd64.
Worth noticing: I am NOT trying to cross-compile.
I'm using go1.6.windows-386 to compile the 32bit version and when I try to compile with GOARCH=amd64 I use go1.6.windows-amd64.
I used TDM-GCC as linux like compile tools.
The error isn't indicative. it just says
c:/WpdPack/Lib/x64/wpcap.lib: error adding symbols: File in wrong format
collect2.exe: error ld returned 1 exit status
Did anyone manage to build this, if it's even possible?
OK so I have figured it out.
In order to compile gopacket 64bit on windows you need to do the following:
Install go_amd64 (add go binaries to your PATH)
Install TDM GCC x64 (add TDM-GCC binaries to your PATH)
Also add TDM-GCC\x86_64-w64-mingw32\bin to your PATH
Install Winpcap
Download Winpcap developer's pack and extract it to C:\
Now the point is that there are missing linux static libraries files
(libwpcap.a and libpacket.a) from lib/x64 folder. I don't know why they weren't
included in the developers pack but anyway that's how we can generate them:
find wpcap.dll and packet.dll in your PC (typically in c:\windows\system32
copy them to some other temp folder or else you'll have to supply Admin privs to the following commands
run gendef on those files gendef wpcap.dll and gendef packet.dll (obtainable with MinGW Installation Manager, package mingw32-gendef)
this will generate .def files
Now we'll generate the static libraries files:
run dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libwpcap.a --input-def wpcap.def
and dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib libpacket.a --input-def packet.def
Now just copy both libwpcap.a and libpacket.a to c:\WpdPack\Lib\x64
That's it.
Now gopacket should compile with no problems.
Thank you so much for the solution, it saved me a lot of time!
Just wanted to add that you can do the same with Npcap, modify the gopacket source code to point to Npcap and it will work too.
In case you don't know Npcap:
https://nmap.org/npcap/vs-winpcap.html
https://nmap.org/npcap/
I installed Npcap on Windows in "Wpcap API Compatibility Mode" and gopacket now works fine.
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory