I'm new to haskell and I'm trying to do my exercise for my class, I've written up the following and tried evaluating the main it but it spits out an error. (In WinGHCi)
Loading package GLUT-2.3.0.0 ... can't load .so/.DLL for: glut32 (addDLL: could not load DLL)
I've tried adding the glut32.dll to my system32 folder and running it again but the same error still pops up. Can someone tell me whats going on?
Heres my code:
import Graphics.Gloss
main = display (InWindow "Exercise One" (200, 200) (10, 10)) black picture
picture = color red (rectangleWire 198 198)
when I compile through powershell using ghc -o test test.hs and ./test and it spits out an error: one.exe: user error (unknown GLUT entry glutInit)
Any help would be appreciated!
You put the glut32.dll file in your system32 directory but if you're on a 64-bit version of windows, it needs to go in your Windows\SysWOW64 directory, with the other 32-bit binaries.
For historical reasons, system32 holds the native OS binaries and are only actually 32-bit on 32-bit windows versions. Despite the name, the binaries in system32 are 64-bit on 64-bit Windows and the 32-bit files go in SysWOW64.
GHC does not have a Win64 port at this time, so it needs the 32-bit glut32.dll.
You could also try putting the glut32.dll in the same directory as the exe you're building.
There is more than one version of glut for Windows; I'd recommend one of the (32 bit) binary builds of freeglut.
Related
I'm trying to cross-compile from WSL and Linux to Win32 using i686-w64-mingw32-gcc. The program is dependent on some DLL:s that I have downloaded, and are known to work when used for an exe cross-compiled on Cygwin. Compilation and linking works without throwing any errors or warnings, but when I run the resulting executable on Windows (by double-clicking on it in an Explorer window) I get a Windows-error-prompt:
The procedure entry point DeleteCriticalSection could not be located in the DLL...
and then it points to the program (the .exe) itself, not a DLL (message translated from Swedish ;-).
When I do the exact same thing on Cygwin with the same archive for the DLL:s and the same DLL:s the resulting exe works as it should.
The new(ish) Dependencies shows some red lines for COMCTL32 and OLEAUT32, but those are the same for both.
A very simple windows GUI app compiles and runs, so it's not the cross-compile as such that is causing the issue. The DLL:s in combination with WSL/Ubuntu/GNU cross-compilation seems to be the culprit.
Instructions
EDIT: after explicitly following my own instructions and explicitly re-installing the cross-compilation tool-chain the instructions below no longer creates a faulty exe. But the original problem remains.
I'm happy to take any ideas on what to try next.
Here are instructions to repeat what I have. Create an empty directory in WSL and run
$ sudo apt install binutils-mingw-w64-i686 gcc-mingw-w64-i686
$ wget https://github.com/DavidKinder/Windows-Glk/releases/download/1.50/WindowsGlk-150.zip
$ unzip WindowsGlk-150.zip
Then create startup.c with the following content
#include <unistd.h>
#include "glk.h"
#include "WinGlk.h"
int winglk_startup_code(const char* cmdline)
{
return 1;
}
void glk_main(void) {
sleep(10);
}
(Fix the capitalized include of "glk.h" in Glk.c or you'll get an error.)
Compile and link with
$ i686-w64-mingw32-gcc -mwindows -I Include/ Glk.c startup.c Glk.lib
to get an a.exe. The message only shows up in Gui-mode so you need to run it from an explorer window:
explorer.exe .
and double-click on a.exe.
WSL and Linux vs. Cygwin
I've done the same cross-compilation on a "real" Ubuntu 20.04 and getting the same problem. Again, doing the exact same steps in Cygwin produces a runable exe. This points to a cross-compilation problem with some facet of
what the exe and the DLL:s are doing. (There is no code in the exe that does anything with critical sections. Could this be an API mismatch?)
Since the DLL:s are the same it is reasonable to suspect the actual cross-compilation of sources in my program.
Is there anything in the cross-compilation toolchain on Linux that might differ? Which Windows run-times and API-versions are targeted?
I'm happy to take any ideas on what to try next.
On freebsd 12 the xwindows module in PolyML is not implemented so I am trying to compile its source outside the ports tree. It does compile, but I cannot open the XWindows module in poly.
What I did is:
copied libX11 to /usr/lib to be sure, and made symbolic links in
/usr/include for Xm and X11 to /usr/local/include.
inserted one space in xwindows.cpp because of a clang error
added these options to configure :
--x-includes=/usr/local/include/X11 --x-libraries=/usr/local/lib/ --with-x --with-system-libffi
set the environment : LDFLAGS=-L/usr/local/lib/gcc7 , where libstdc++
is located
tried with clang and gcc7
The code compiles without further errors. There is a file xwindows.o, 375160 bytes for cc and 291184 for gcc7.
The log contains
Created structure XWindows
Created structure Motif
I run poly from where it was compiled, and get
open XWindows
poly: : error: Structure (XWindows) has not been declared Found near open XWindows.
The non-graphics modules open normally
What am i doing wrong here ?? thanks for pointers
I
added CONFIGURE_ENV= LDFLAGS=-L/usr/local/lib to the port's Makefile, and
inserted a space before ZERO_X in xwindows.cpp
after which the ports code compiled, including the 2 modules in poly
My error has been to omit a make rmconfig before new compilation, and I had originally compiled poly without motif, so that kept coming back
I've installed Haskell Platform version 8.2.2 (Full, 64 bit) on Windows 10. ghc works, and also WinGHCi. There are several problems:
-- Running ghci in cygwin gives this error:
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 193)) Whilst trying to load: (dynamic) pthread Additional directories searched: (none)
-- Running ghci in PowerShell just causes PowerShell to freeze
-- Installing packages with cabal produces a similar error message
-- ghc-pkg check produces a large number of warnings, including many that refer to ghc-8.0.1, which is the most recent version of ghc that works on my computer
GHC_PACKAGE_PATH is not set. I can't find anything in my configuration that refers to ghc-8.0.1. (The cabal.config file contains the definitions given in the Haskell Platform download page.)
What is the cause and the cure for the error message ": user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 193))?
I can't post in comments so I'll provide what I found here. Feel free to delete my "answer" if this doesn't follow any stackoverflow guideline.
I ran into the same error with a fresh install of the full 64bit Haskell Plateform on Windows 10.
I tried messing around with the pthread.dll submitted by another project (Lilypond to be exact). I added it to one of the additional directories added by Stack when ghci is run through stack ghci.
Ghci can find it but can't load it. So the problem isn't about ghci failing to find any stuff related to pthread.
Here is the output for reference:
$ stack ghci
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
<command line>: user specified .o/.so/.DLL could not be loaded (addDLL: C:\Users\Alice\AppData\Local\Programs\stack\x86_64-windows\msys2-201505)
Whilst trying to load: (dynamic) C:\Users\{user}\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin\pthread.dll
Additional directories searched: C:\Users\{user}\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin
C:\Users\{user}\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
I don't have any further information yet. However I hope what I provided can help.
Try running GHCI with system administrator permissions (type "Command Pro..." into Start and click "Run as administrator").
If ghci now works then the problem was solved because you now have access to the file c:\Windows\System32\pthread.dll.
To use ghci without Admin permissions (recommended), change the permissions (while you have admin permissions) so that user can read the pthread.dll file:
C:\> CACLS c:\Windows\System32\pthread.dll /e /p your-username:r
(replace your-username with your actual username)
Credit for this fix goes to this post: https://faculty-web.msoe.edu/hasker/cs3040/ghc-install.html
This page illuminates: http://euterpea.com/troubleshooting/
"Trying to start GHCi, WinGHCI, or running GHC fails with errors related to pthread.dll, such as: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 193))
If you have Lilypond installed, this is unfortunately a known incompatibility with recent versions of Haskell Platform right now. There are only three ways to solve it for now:
Option 1: Remove Lilypond’s bin folder from your PATH environment variable. If you have a user path and a system path, you must remove Lilypond-related entries from BOTH, not just the user’s path. You may need to reboot for GHCi to work again. You should still be able to run the GUI for Lilypond by making a desktop shortcuts directly to Lilypad.exe. If using from command line, calling the executables with the full path to the containing folder. Unless you used a custom installation location, the Lilypad, lilypond, midi2ly, and other programs that come with Lilypond will be located in this folder: C:\Program Files (x86)\LilyPond\usr\bin
Option 2: Use Haskell Platform 8.0.2a (core or full).
Option 3: Uninstall Lilypond. This is only recommended if it’s an old installation and you don’t plan on using it anymore. Otherwise, try option 1 first."
HTH
I'm attempting to compile a relatively simple Fortran executable so that it can be passed around to other Windows users that don't have Cygwin (or something of the sort) installed, however, I'm unable to get the executable to operate as a standalone. I've tried gfortran -static file.f and gfortran -static-libgfortran file.f, however other users always encounter this error:
The program can’t start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem.
From what I've read online (e.g. here), the -static option should be sufficient. I have verified that running the executable from my machine (DOS prompt) does work.
I have gcc (gfortran) version 4.7.3. I should also point out this is my first attempt at compiling portable Fortran.
Update
After realizing that this isn't a gfortran-specific issue (thanks to replies here), searches led me to related posts here and here
This is partially explained in the Cygwin FAQ. The solution is to install the mingw64-i686-gcc-fortran package with its dependencies, and cross-compile your code with i686-w64-mingw32-gfortran -static.
Just package the cygwin1.dll along with your binary file (both in the same folder) then it will run just fine.
We have linked PHP Code with C++ code using PHP Extension code (written in C++ only)... which all were working fine in 32bit OS.
Now we changed the version of many s/w as the OS version is changed to 64bit. We Compiled the C++ code which was previously running fine using 64bit gcc to 32bit ".so" file it shown many errors and we cleared all those and finally compiled successfully. But during linking with PHP it's showing:
undefined symbol: _ZTV5Temps" error
Use c++filt to demangle the name:
$ c++filt -n _ZTV5Temps
vtable for Temps
My guess (given the lack of context) is you have a reference to Temps (class) in a module that has not been recompiled/relinked.