I'd like to build application using Gstreamer 1.0 and GTK+-3.0 on Windows 8 (64bit).
I have sucessfully install and build GTK+-3.0, 32 bit version using Dev-C++ and Mingw 32-bit (there is no 64 bit version of GTK+). Everything works perferkt. It also installed pkg-config, I addeded it in %PATH% and it works.
I have installed gstreamer-1.0-devel-x86-1.4.4.msi and gstreamer-1.0-x86-1.4.4.msi from here
1) First problem: it installed itself into I:\gstreamer\ without asking me. I am very unhappy about it, I'd like have it on C:. But its not the biggest problem.
2) pkg-config do not know about gstreamer. I have found in I:\gstreamer\1.0\x86\lib\pkgconfig\ *.pc files, so I looked into gstreamer-1.0.pc and added to my projekt this options:
C compiler:
-I"I:/gstreamer/1.0/x86/include/gstreamer-1.0/"
Linker:
-L"I:/gstreamer/1.0/x86/lib" -lgstreamer-1.0
3) Now the program was compiled, but when I run it, it was not able to find gstreamer-1.0-0.dll. So i tried copy I:\gstreamer\1.0\x86\bin\gstreamer-1.0-0.dll into to the same directory as is my compiled file. Then it was not able to find libwinptread-1.dll. So I copied it also.
Then te program run, but it faild with some error like "cannot find entry point to windows thread ..." (I do not remember it exactly). So I copied ALL dll files from I:\gstreamer\1.0\x86\bin\ and then finally the program run.
But now it is not able to create elements:
source = gst_element_factory_make ("videotestsrc", "source");
//source is null
So, my question is, how to install gstreamer, that my program will find all dll files and will be able to create elements?
installing -- choose "custom install", there you can change the installation path.
for vs you can use *.props (gstreamer\1.0\x86\share\vs\2010\libs)
you need set Environment variable - GST_PLUGIN_SYSTEM_PATH_1_0 to plug-ins. For more details see http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html
Related
I am attempting to set up GTK3 for development on Windows 10 following the instructions on tarnyko.net
using the 64bit 3.6.4 bundle from here. The test program currently builds without errors, using the generated options. When I run the program a dialog appears displaying the error message:
Procedure entry point deflateSetHeader could not be located in the
synamic link library C:\Gtk\bin\libgio-2.0.0.dll
From what I can tell so far, deflateSetHeader is a function in zlib that was not present in older versions - a possible cause for the error. Looking in the header file of zlib that came with Gtk, it lists the function.
I have copies of zlib1 in my Gtk bin dir and MinGW (GCC v7.2.0) bin dir.
I tried swapping the versions between directories, but no joy. Don't have much else in my environment path variable, except for a vanilla Python 3.6 install. Don't have zlib1 in SysWOW64. I tried adding -lzlib1 to my gcc compiler options, but that didn't seem to make a difference. I'm running out of ideas now.
Anyone know what might be causing this?
Found the cause by searching my C drive for zlib and found a copy in
C:\Program Files\Intel\WiFi\bin that was causing the problem.
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.
Has anyone succeeded in installing gtk2hs on Windows? I am using Haskell Platform 7.10.2a on Windows 10, both 64-bit, and tried running "cabal install gtk3", but it failed on the gio package with error message:
gcc.exe: error: unrecognized option '-pthread'
(Edit extra note: next line of error message below)
compiling dist\build\System\GIO\File\FileAttribute_hsc_make.c failed (exit code 1)
It appears that the gcc in the mingw subfolder in the Haskell Platform package is a little outdated. Is there any way to update this subfolder? The only clue I found on the Internet is the link below, which does not seem to offer any solution:
https://ghc.haskell.org/trac/ghc/ticket/10726
(Edit: version of gcc seems unrelated. '-pthread' switch appears to be invalid for gcc when run under Windows, it's only valid in Linux, see this link, but I have no idea why GHC/GTK3 is using -pthread and no idea how to change this to -mthread http://mingw-users.1079350.n2.nabble.com/pthread-vs-mthreads-td7114500.html)
Before running cabal, I installed GTK+ 3.18.0.1 on Windows using MSYS2.
I have installed gtk2hs on Linux easily with no issues at all.
Update: Also got GTK3 (bundle from below) running a Windows 10 64 bit device.
The additional step I had to accomplish was to include the libintl.def and
libintl.dll.a from an older bundle into the lib folder. I obtained those two files from a GTK2.x bundle, i.e. https://download.gnome.org/binaries/win64/gtk+/2.22/gtk+-bundle_2.22.1-20101229_win64.zip.mirrorlist, otherwise cabal was complaining about the missing C library intl. To sum up:
1) Obtain a GTK3 x64 bundle from the link http://www.tarnyko.net/dl/gtk.htm.
2) Obtain the missing files libintl.def and libintl.dll.a from an older
bundle, i.e. GTK2 (link from above) and include them in the lib folder.
3) Install glib first, run cabal install glib. Ensure that you have administrator privileges and GTK3/bin is on your PATH variable. Additionally,
you can set LIB and INCLUDE pointing to the GTK/lib and GTK/include folder respectively (might not be necessary).
4) Run cabal install gtk3 finally. You may use the flag --global.
(Tested on Windows 10, 64-Bit, Haskell Platform 8.x)
Installation steps for Windows 7, 64-Bit: (Original Post)
I figured it out how to install GTK3 on Windows7 (64 bit) when running
Haskell Platform 7.10.3. Therefor, I had to accomplish following steps:
Download the gtk3 64-bit bundle from http://www.tarnyko.net/dl/gtk.htm (personally I have used the 3.6 version of it)
Download the gtk3 binding https://hackage.haskell.org/package/gtk3 (0.14.5)
Install the dependencies separately. This encompasses the libraries gio, glib and pango (not cairo in my case). (cabal install package-name)
Adjust the gtk3.cabal file. I have removed following lines (all are within 5 lines):
if os(darwin)
cpp-options: -D__attribute__(A)=
-DWIN32 (just that one flag)
extra-libraries: kernel32
Adjust the gtk.h file (comes with the gtk3 bundle, include\gtk-3.0\gtk) I have defined following macros BEFORE the include operation of #include :
define GDK_VERSION_3_0 (G_ENCODE_VERSION (3, 0))
define GDK_VERSION_MIN_REQUIRED GDK_VERSION_3_0
define GDK_VERSION_MAX_ALLOWED GDK_VERSION_3_6
define GDK_DISABLE_DEPRECATION_WARNINGS
Add the path of the MinGW and gtk3 folders bin, include, lib to the PATH variable.
Run cabal install gtk3.cabal
Following tricks also helped me (command line parameters):
--gcc-options="C=LANG"
--with-gcc="path to gcc.exe"
--global
To be honest, this was more luck than knowledge. Took me several hours
to find a workaround. I had the same troubles with the gtk2 bindings for haskell. (Installing gtk2hs failure)
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
Apologies for the tardy title, I'm not quite sure how to phrase this question. At its most basic, I'm attempting to compile a program with GStreamer. When running the configure script for said program I get the following error:
0:20.39 configure: checking for gstreamer-1.0 >= 1.0
0:20.39 gstreamer-app-1.0
0:20.39 gstreamer-plugins-base-1.0
0:20.39 configure: error: gstreamer and gstreamer-plugins-base development pack
ages are needed to build gstreamer backend. Install them or disable gstreamer su
pport with --disable-gstreamer
The build environment I'm compiling in:
Windows 7 (64-Bit)
MINGW & MSYS
Visual C/C++ 2010 SP1 (command line)
Now if this error occurred on a Linux distro, - say Ubuntu - it could be remedied by running the following commands:
apt-get install libgstreamer-plugins-base1.0-dev
apt-get install libgstreamer1.0-dev
What is the equivalent for Windows? I've found two type of versions that can be used: The gstreamer bin from the developer website, which has the following structure:
bin
include
lib
share
And a dynamic library of gstreamer for mingw with the following structure:
bin
lib
How am I supposed to let mingw/msys know that the gstreamer library is installed? Do I place the folders above in the relevant MSYS directories? Then, how does the configure know that it's installed and ready to be used?
I hope what I'm asking makes sense, please let me know if anything is confused. Cheers!
Using the first solution (official binaries from GStreamer), you need to tell the configure script where everything is located.
The simplest way is to set the environment variable PKG_CONFIG_PATH to where the .pc files are located. Generally it's in
$install_directory/lib/pkgconfig/
Replace $install_directory with the actual location, ex if it's installed in /c/GStreamer :
PKG_CONFIG_PATH=/c/GStreamer/lib/pkgconfig ./configure
That should make configure figure out everything