I've compiled haskell program which uses wxHaskell library, now I would like to know how to make it run on other machines which doesn't have wxHaskell installed. Of course I can see errors and I can copy dlls written in output and copy them to that machine but what is professioal sollution, can I write any installer or something like that?
thanks for help
You will need to fully statically link your executable. How to do this varies from system to system, but in general involves passing the -static flag to GHC, and -optl-static to your linker.
If you use the recent cabalized wxHaskell implementations, it's pretty easy, since almost everything is statically linked.
I use InnoSetup, which is Open Source, and works very well. My script needs at least the following:
AppName=My Wonderful Application
AppVerName=My Wonderful Application 0.1.13
CreateAppDir=yes
DefaultDirName={pf}\MyWonderfulApplication
[Files]
Source: "path\to\your\wxWidgets.dll"
Source: "path\to\msvcrt.dll"
Source: "path\to\your\application.exe"
All of the paths except DefaultDirName are paths on your development machine.
The key items are your wxWidgets DLL (may be multiple DLLs, depending on how you built wxWidgets - I recommend and use the monolithic option, which creates a single DLL, wxmsw28u_gcc_custom.dll) and your application binary.
If you are linking to any other libraries, you will need them as well. Many 3rd party libraries on Windows require msvcrt.dll, which is why I've mentioned it.
Related
Yesterday I compiled the necessary files to create the schemas but let me wondering why it was necessary to do all these steps to create the schemas, why those executables can't be shared directly as a release, is there something I'm missing?
We do provides a win32 executable for releases (https://github.com/google/flatbuffers/releases), and there are executables for Linux / OSX / Win for every commit and CI run here: https://github.com/google/flatbuffers/actions
Providing executables for Linux that will serve everyone is relatively difficult, with every distro having different versions of glibc and Linux somehow being static linking unfriendly, 32 vs 64 bit etc. So the CI executable may or may not work for you.
On Windows, a single statically linked win32 executable works for everyone, and Windows people are less used to compiling things themselves, hence why we provide it.
I use Cygwin to build source code to DLL used by windows app.
When I use GCC core / GCC g++, the app crash if it calls function (which includes printf or malloc) in DLL.
When I use Mingw64-x86_64-gcc-core / Mingw64-x86_64-gcc-g++ it reports error like sys/socket.h：No such file or directory.
Can anyone explain how to do it? Thanks.
The first problem is due to the tentative to build a stand alone DLL (not depending on cygwin1.dll) using cygwin only specific tools.
You have collision between multiple malloc and other C library call present in cygwin1.dll.
The second is due to the fact that sys/socket.h does not exist on Windows
see for possible solution:
Using sys/socket.h functions on windows
So you need to define what is your target : Cygwin/Posix or Windows and choose programming style and tools accordingly, you can not mix.
Given a Cygwin executable, how do i find out all the dll's that it depends upon?
For the libraries that are loaded by the system executable loader i can use a tool like depends (aka Dependency Walker), but i have no idea how to trace the dll's that the program tries to load dynamically with Load Library.
My aim is to be able to take the minimal dependencies of a program built for Cygwin platform in order to make it work portable, without all the Cygwin stuff that it is never gonna use (some base command line utils, man pages etc.).
Any help is appreciated!
Thanks to Michael Lockhart, the solution is simply to cygcheck the executable. Here are some references: on Wordpress and his site.
What I am looking for:
Download library
Extract It
Apply custom patch
Run configure
Run build command
What library I am trying to build are:
Openssl
Boost
Thrift
C-ares
Curl
Pcre
Nginx
ICU
JsonCPP
I think I can do these things using external module: http://cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject
But I have following question?
I have different type of build and with different directory. Is it
going to build all these library for every different target? If yes
it will be painful as all these library take one hour to build. Is
there a way I can control it and it only build it once. As library
remains same for all these targets.
On switching directory to different name. Cmake force everything to
be rebuild-ed. Will it be same for external library. If yes? How to
solve this problem. I don't want to rebuild the library if I am not
changing them and want to use them while switching to different
branches without building them.
Yes, you can use CMake's ExternalProject feature to accomplish what you want to do.
When using cross-compilation in combination with external projects, the source code will be built once for each toolchain. You could avoid rebuilds if you checked in the results of the build into a source-control system, and re-checked it out on each new person's machine, but I do not recommend this. Instead, have one of your "set up new computer" tasks actually be allowing the compilation to run overnight, which will also act as a test that the machine is actually usable. That set-up task can be launched by a system administrator prior to a new hire's arrival, or you can leave it to the new hire, as circumstances require.
I'm not completely certain what you are asking in your second question, but if the library is unchanged, CMake will detect that it is unchanged and not recompile it. Typically, the source code would be in a single directory tree: each compiled version would be built in a distinct location. Thus, developers can access any compiled version at any time just by switching directories. This is particularly helpful because it allows you to mount these directories over NFS to embedded hardware, et cetera.
For a wxHaskell based application distributed on Windows, can I distribute the necessary WX DLLs right alongside the application, without having to do a separate install of WX?
I want to be able to distribute the application as a zip file and not require the user to have anything installed. Is that possible?
I'm by no means a wxHaskell or a wxWidgets expert, but...
For your use case, it sounds like you want statically linked libraries, not DLLs. WxWidgets seems to be fine with that. So if you use ghc -static -optl-static -optl-pthread, you should get the result you want.
Some annotation: the -static option isn't really necessary: it's ghc's default. The -optl options get passed to gcc. -optl-static statically links in any C libraries you're using (and I imagine wxHaskell uses some). And -optl-pthread is black magic to me, but it seems like a good idea.