I am trying to write a Haskell program that simulates keystrokes on Windows. I tried to call keybd_event and SendInput, but neither one compiled. I can run the program with the interpreter, though. When I try to build the program when it contains a binding to SendInput in winable.h, I get the error:
cabal install
...
[1 of 2] Compiling WindowsKeys ( dist\build\WindowsKeys\WindowsKeys-tmp\WindowsKeys.hs, dist\build\WindowsKeys\WindowsKeys-tmp\WindowsKeys.o )
[2 of 2] Compiling Main ( src\Main.hs, dist\build\WindowsKeys\WindowsKeys-tmp\Main.o )
Linking dist\build\WindowsKeys\WindowsKeys.exe ...
dist\build\WindowsKeys\WindowsKeys-tmp\WindowsKeys.o:fake:(.text+0x35d): undefined reference to `SendInput'
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
WindowsKeys-0.1.0.0 failed during the building phase. The exception was:
ExitFailure 1
The verbose error is at http://pastebin.com/trg21N0x , but it doesn't seem to contain any more clues. I get a similar error when I try to use keybd_event.
The hsc file I wrote includes these headers:
#include "windows.h"
#include "winuser.h"
#include "winable.h"
Here is the C binding:
foreign import ccall unsafe "winable.h SendInput"
c_SendInput :: UINT
-> Ptr Input
-> CInt
-> IO UINT
I assumed that I could not call SendInput on winuser.h because of the #if :
#if (_WIN32_WINNT >= 0x0403)
WINUSERAPI UINT WINAPI SendInput(UINT,LPINPUT,int);
When I add a binding for _WIN32_WINNT , the value is 0x400.
I have version 2012.4.0.0 of the Haskell Platform. It came with a folder of headers containing the ones that I included. I could not find any other headers with the same names on my computer. I am using Windows 7 Professional, version 6.1 .
Thank you!
Here is WindowsKeys.cabal :
-- Initial WindowsKeys.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
name: WindowsKeys
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.8
extra-source-files: windows.h, winuser.h, winable.h
executable WindowsKeys
main-is: Main.hs
other-modules: WindowsKeys
build-depends: base ==4.5.*, Win32 ==2.2.*
hs-source-dirs: src
build-tools: hsc2hs
extra-libraries: user32
include-dirs: src
The build succeeds when I comment out the bindings to the keyboard functions.
I finally found that I had used the wrong calling convention. keybd_event and SendInput both need to be called with stdcall instead of ccall.
Related
I'm trying to use GLFW with rust on windows and I'm getting this error upon running the program:
error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
|
= note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--dynamicbase" "-Wl,--disable-auto-image-base" "-m64" "-Wl,--high-entropy-va" (then a ton of other stuff that leaks my files)
= note: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglfw3
collect2.exe: error: ld returned 1 exit status
All I am doing in the program is importing the package.
I have been trying to solve this for a while, and it doesn't help that I'm very new to rust. I guess this is what I get with trying to use rust on windows.
Thanks for your help!
Add a -L<path> linker flag where <path> points to the folder containing libglfw3.a (or libglfw3.dll.a in case of shared library).
Platform: Macos Catalina 10.15.2
Xcode version: Xcode 11
I have tried many times to make-all gcc to build my source code. However, I have encountered a problem:
In file included from ../.././gcc/c/c-objc-common.c:33:
In file included from /Applications/Xcode11.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/new:85:
/Applications/Xcode11.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/exception:181:5: error:
no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~~~~~ /Applications/Xcode11.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:873:15: note:
expanded from macro '_VSTD' # _VSTD std::_LIBCPP_ABI_NAMESPACE
^ ../.././gcc/system.h:685:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char
*) ATTRIBUTE_NORETURN;
^
1 error generated.
make[1]: *** [c/c-objc-common.o] Error 1
make: *** [all-gcc] Error 2
I have tried to install another version of Xcode. I have installed Xcode6 but it still did not work, and I found a solution of this issue. But when I download Xcode8.3.3, it is not compatible with Catalina 10.15.2.
I ran in to this issue while using crosstools-ng on mac (mojave 10.14) to compile cross-platform toolchain with gcc 4.9.
Solution: Edit .build/src/gcc-4.9.4/gcc/system.h to add #include <map> in #ifdef __cplusplus block where other include statements are.
The problem is that is included (via ) after abort has been
defined as a macro to fancy_abort. And thus when the C++ standard headers try
to call std::abort, they end up calling std::fancy_abort, which of course
doesn't exist.
Source: https://gcc.gnu.org/legacy-ml/gcc-bugs/2017-09/msg00154.html
I'm trying to build / install the WWW::Curl module for strawberry perl.
I had to make some adjustments in Makefile.PL according to instructions in: http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32
and in here: Installing WWW::Curl on WIndows 7, running into "List form of pipe open not implemented"
When I execute perl Makefile.PL, at the command prompt, I get the following messages:
Found curl.h in d:\curldev\include\curl\curl.h
Building curlopt-constants.c for your libcurl version
Building Easy.pm constants for your libcurl version
Building Share.pm constants for your libcurl version
Warning (mostly harmless): No library found for -lcurl
Warning (mostly harmless): No library found for -lcurldll
Writing Makefile for WWW::Curl
Writing MYMETA.yml and MYMETA.json
After that, when I run dmake I get the following error message:
D:\perl\cpan\build\WWW-Curl>dmake
Skip blib\lib\WWW\Curl\Share.pm (unchanged)
Skip blib\lib\WWW\Curl\Form.pm (unchanged)
Skip blib\lib\WWW\Curl.pm (unchanged)
Skip blib\lib\WWW\Curl\Easy.pm (unchanged)
Skip blib\lib\WWW\Curl\Multi.pm (unchanged)
gcc -c -Id:\curldev\include -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IM
PLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -s -O2
-DVERSION=\"4.15\" -DXS_VERSION=\"4.15\" "-ID:\perl\perl\lib\CORE" Curl.
c
Curl.xs: In function 'XS_WWW__Curl__Easy_init':
D:\perl\perl\lib\CORE/XSUB.h:526:20: error: 'PerlSIO_fread' undeclared (first us e in this function)
D:\perl\perl\lib\CORE/XSUB.h:526:20: note: each undeclared identifier is reported only once for each function it appears in
Curl.xs:620: confused by earlier errors, bailing out
dmake: Error code 129, while making 'Curl.o'
The questions is: what is causing this error?
May be it has something to do with the Warning lines in the messages after running Makefile.PL, but not sure.
Thanks in advance.
This might sound crazy but, I was able to get over this by commenting out the undeclared variables in the corresponding file. It also complains about PerlISO_fwrite or something similar. you will have to comment that as well
https://rt.cpan.org/Public/Bug/Display.html?ShowHeaders=1;id=62609
Adding this to the curl.xs file fixes it:
#include "XSUB.h"
/* add new code here */
#ifdef fread
#undef fread
#endif
#ifdef fwrite
#undef fwrite
#endif
/* end new code */
#include <curl/curl.h>
This is kind of linked to this question here: GtkD (the Gtk+bindings for the D language) why compile it?
I'm using GtkD with the D programming language on Ubuntu 12.04 and i'm stuck trying to statically link the compiled libs with my program. Once GtkD is compiled there are three libraries
libgtkd.a
libgtkdgl.a
libgtkdsv.a
After doing make install these are placed into the /usr/local/lib/ folder and the GtkD source is placed inside the /usr/local/includes/d/ folder. I've also compiled the source to *.di files and placed them in the relevant folders in /usr/local/includes/d/ as the make script doesn't do this by default.
Here's the source i want to compile.
pragma(lib, "/usr/local/lib/libgtkd.a");
import gtk.MainWindow;
import gtk.Label;
import gtk.Main;
void main(string[] args)
{
Main.init(args);
MainWindow win = new MainWindow("Hello World!");
win.setDefaultSize(200, 100);
win.add(new Label("Hello World"));
win.showAll();
Main.run();
}
Here's the compiler command i use:
rdmd -L-ldl hello_world.d
Here's the errors:
/usr/local/lib/libgtkd.a(Loader.o): In function `_D4gtkc6Loader12pLoadLibraryFAyaE4gtkc6Loader4RTLDZPv':
src/gtkc/Loader.d:(.text._D4gtkc6Loader12pLoadLibraryFAyaE4gtkc6Loader4RTLDZPv+0x28): undefined reference to `dlopen'
src/gtkc/Loader.d:(.text._D4gtkc6Loader12pLoadLibraryFAyaE4gtkc6Loader4RTLDZPv+0x31): undefined reference to `dlerror'
/usr/local/lib/libgtkd.a(Loader.o): In function `_D4gtkc6Loader10pGetSymbolFPvAyaZPv':
src/gtkc/Loader.d:(.text._D4gtkc6Loader10pGetSymbolFPvAyaZPv+0x23): undefined reference to `dlsym'
src/gtkc/Loader.d:(.text._D4gtkc6Loader10pGetSymbolFPvAyaZPv+0x2c): undefined reference to `dlerror'
/usr/local/lib/libgtkd.a(Loader.o): In function `_D4gtkc6Loader14pUnloadLibraryFPvZi':
src/gtkc/Loader.d:(.text._D4gtkc6Loader14pUnloadLibraryFPvZi+0x9): undefined reference to `dlclose'
collect2: ld returned 1 exit status
--- errorlevel 1
shell returned 1
Any ideas what i'm doing wrong? It looks like an ld error but that's linked right?
The order of arguments matters with ld, the linker. In general you should place dependencies after the code/library which depends on them. So I'd rewrite your pragmas like so:
pragma(lib, "gtkd"); // let ld find it in your path
pragma(lib, "dl"); // gtkd depends on dl, so link it after
Now try compiling with:
dmd hello_world.d
you pass it along in the arguments dmd knows that they need to be passed to the linker
rdmd libgtkd.a libgtkdgl.a libgtkdsv.a -L-ldl hello_world.d
I've been trying to get a super simple SDL program to work. I'm using Mac OS X Lion. I've got SDL to work in Snow Leopard, but it doesn't seem to want to work in lion. So far I have this:
#include <iostream>
#include "SDL/SDL.h"
using namespace std;
/*
#ifdef main
# undef main
#endif
*/
int main( int argc, char* args[] )
{
SDL_Surface* hello = NULL;
SDL_Surface* screen = NULL;
SDL_Init( SDL_INIT_EVERYTHING );
screen = SDL_SetVideoMode( 640, 480, 32, SDL_SWSURFACE );
hello = SDL_LoadBMP( "hello.bmp" );
SDL_BlitSurface( hello, NULL, screen, NULL );
SDL_Flip( screen );
SDL_Delay( 2000 );
SDL_FreeSurface( hello );
SDL_Quit();
return 0;
}
When I try to compile this code (in Xcode 4.1) it gives me this error:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
(maybe you meant: _SDL_main)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
If I uncomment the #ifdef stuff I have commented currently, the program compiles, but then receives SIGABRT on the SDL_SetVideoMode line. That commented stuff I have I just saw in another program, I'm not sure if I'm supposed to have it or not.
How am I supposed to get this working?
The SDL header files redefine main with a macro. This is in SDL_main.h:
#define main SDL_main
But this is fine. SDL provides its own main() function that then calls your version. So get rid of those defines, they are making it worse, not better.
If your project is Cocoa based, then you probably missed to include SDLmain.m in your project. This provides a Cocoa friendly main() function. If your project is native C++, then my guess is that you did not include all the SDL libs in your project, so the linker isn't seeing SDL's own main().
If you are using the SDL framework you simply need to add the files SDLMain.h and SDLMain.m to your project (assuming you already have added SDL.framework to your project).
You find these files in the "devel-lite" folder of the SDL diskimage, which you can download here: http://www.libsdl.org/release/SDL-1.2.15.dmg
These two files will give you a Cocoa-friendly main routine, so that your SDL application can be a well-behaving OS X application.
SDL.h does not include SDL_main.h
The first line in your file should be:
#include SDL_main.h
SDL_main redefines the main function and then does its own initialization the is required to get SDL working with OS X
When compiling, you will also need to link in libSDLmain in addition to libSDL
I had the same link time error as OP for a pure C++ & OpenGL app, and the solutions was to use the sample project from https://github.com/Ricket/HelloSDL
This made me add the Cocoa libraries but that would have been needed anyway since I was targeting the iPhone.