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.
Related
I really like live smalltalk environment (though I only experimented a bit with Pharo), but there is one thing why I can't really use it for everyday development. It seems that it is not possible to create a native standalone executable from smalltalk system. The native standalone executable means to create a single executable file (PE on windows, ELF on linux, Mach-O on macosx), that a user could run by double clicking it without the need to install any additional execution environments. Am I missing something and it is in fact possible to create native standalone executable with smalltalk?
If we talk about Pharo specifically. I know that Pharo's environment includes efficient just in time compiler (that generates true native code from Pharo's VM bytecode), I know that the VM image can be stripped down by cutting of the code that my application won't ever need. So basically we already have almost everything (except the linker I guess) to be able to create native standalone executables. Cross-compilation shouldn't be a problem too, if we put all code generation stuff (for all target processors) in the image.
I know that in smalltalk world it is considered to be a good thing to deliver the whole VM image separately from the runtime environment, so the user can hack on software he/she is using. However I don't see any good reasons why it shouldn't be possible to deliver your smalltalk software as fully compiled native standalone executable. Could you please explain me why it is not a common thing to do in smalltalk world? Is there any good smalltalk implementation that allow to do it?
To sum all this. I dream of a live smalltalk environment, where I could develop and test my software, but then (when the software is actually ready for delivery) cross-compile it to native executables for windows, linux and macosx from my single development machine. That would be really awesome.
ironically enough there is one thing that an exe needs to be preloaded. Your OS. See the thing is that C/C++ can be so light because already your OS acts pretty much as the image acts with a ton of preloaded libraries. You need to waste several GBs of memory just get a simple calculator starting. Your OS is a collection of C/C++ libraries.
Things are not any prettier with other languages like python, java etc , even if the app is smaller, they still depend on this libs and they come will quite big libraries that would need installation whether your app use them or not.
Pharo and Smalltalk in general is diffirent case because they aspire to be a virtual OS by itself. The diffirence with a real OS , the smalltalk image is made to be hacked the easy way by a user .
Saying that you can rename the pharo executable, change its icon, disable to IDE tools inside Pharo so your user sees only the GUI of your App. Applications like Dr. Geo and Phratch already do this.
Compiling a Pharo project to a native executable will not make much difference, because a) Pharo is already compiled to a native executable b) you dont need to do that since Pharo is already standalone does not need to even be installed.
My advice is stop worrying about things that do not really matter and enjoy learning how powerful and fun Pharo can be.
Not Pharo, but native, compiled (through ANSI C or its own JIT) smalltalk [applications] (with ability to load pre-compiled DLLs or [JIT-]compile code on demand):
Smalltalk/X
http://www.exept.de/en/products/smalltalk-x.html
or (unofficial enhanced development version):
Smalltalk/X JV branch - https://swing.fit.cvut.cz/projects/stx-jv/
Nearly completely open-source. Everything except librun (core runtime - memory management, JIT, etc.) and stc (smalltalk-to-c) compiler is already open-source. Claus Gittinger / Exept also promised/confirmed they would release remaining sources were they to stop further development (AFAIK, those parts are closed only because of concerns of existing clients).
I highly recommend everyone to check it out, it is a wonder such a great implementation is so little known.
You might also check out Dolphin from Object Arts.
It is windows only, but the very best IDE, bar none.
If you do anything in Smalltalk, you should buy a copy.
(They also have a free non-commercial version, but you will
want to support the kind of craftsmanship behind it by buying
the Pro version. An absolutely kick-ass product, IMHO).
It will produce a standalone exe, if that's what you want.
I made an exe of a medium-featured wiki with it - the exe was
less than 1 MB. That is not a typo.
-Jim
The problem is that Pharo, in that case, cannot be compared to any native compiler like C, C++ or others, but more like java, python, ruby and other languages with a Virtual Machine around.
In these languages, you produce jars, eggs or gems to distribute your project.
In Pharo, you produce a "production image" following technics you already mentioned. But nothing prevents you to deliver an artefact including also the PharoVM (it is 2m large, after all), and you can prepare your apps to detect and open your production image (without having to ask for it).
It is about as practical with Smalltalk as with other languages: not very much. As soon as you create a somewhat larger application, you start depending on other libraries/applications being installed. If you compile them statically with the application, you have now created a much larger application that takes longer to download, and needs to be updated at least as soon as a security problem is found in one of the dependencies. If not, your application is no longer double-click startable.
There are two directions for solutions: web applications, and installers and package managers.
Squeak still maintains its one-click installer, allowing the same set of files to work on windows, mac and linux. Pharo used to have that too, but moved to having separate builds. The need hasn't been so large that the one-click build has been reinstated. It is mostly seen as useful to be able to carry around a cross-platform environment on an usb-stick. With the move to the 64-bit spur vm the dependency problems will lessen as more of the needed libraries will come pre-installed on those platforms.
Dolphin Smalltalk can produce a standalone .exe for Windows.
This is a key feature of the Pro version.
Your dream has been around since the mid-80's and it is called Smalltalk/X.
The mono installation provided at mono-project.com comes packed with several libraries, such as gkt, making the installation quite large (~280MB or so).
Is there any way to provide users with an installation of "just" the mono environment? I am targeting Windows, MacOSX and Linux.
You might be looking for mkbundle which merges your application, the libraries it uses and the Mono runtime into a single executable image. See under "Bundles" in that page.
If you do this though, it may mean that you are distributing LGPL code with all that this implies.
If you are distributing your app for Mac OS X, there is also MonoMacPackager which offers more advanced support for this. I think they have done a bunch of work in the linker to really minimize the amount of Mono that you have to include. It will actually remove unused code from assemblies that you reference.
I'm currently trying to get g++ working, and looking at http://gcc.gnu.org/install/build.html, I can't seem to find where it says how "to perform a 3-stage bootstrap of the compiler". Where would I find this information?
(I'm on a mac, in case that matters.)
After running configure, you do make bootstrap
You cannot bootstrap GCC without an already-functioning compiler on your platform:
From the prerequisites page:
ISO C90 compiler
Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (K&R) C compiler.
And to preempt your next question, you also need a functioning compiler (usually GCC) in order to build Clang+LLVM.
It might be possible to do what you're trying so hard to do, by cross-compiling GCC from some other platform (see this section of the documentation). But I imagine this is not for the feint of heart, and you'd be far, far better off simply updating your copy of Mac OS X to the latest version with Xcode support.
From that link:
For a native build, the default configuration is to perform a 3-stage bootstrap of the compiler when `make' is invoked.
It seems to me that if your configuration isn't tweaked, it should do it out of the box. Just type make.
More specifically, you have to download the source code, and follow the instructions in that whole tutorial in order to build.
A side note - I am finding it hard to believe that there is no easy way to get GCC on an OSX box without having the installation media. That sounds really annoying :)
Edit:
If you are simply trying to write C++ on OSX, you could install one of many other IDEs. If you are lucky, they may come with their own compiler. Here is a list of alternatives to XCode:
http://alternativeto.net/desktop/xcode/?profile=mac&platform=mac
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.
I'm planning to write a C library which will act as an umbrella "wrapper" around several other libs. Some of the libraries will be GPL and some will be proprietary. Moreover, some of the libraries may not be available at compile time, so I plan to have autotools detect them during configure. I'm also wondering if I should build in support for these weak dependencies and then also detect them at run-time -- particularly for the proprietary libs. Here's why:
Without going into specifics, the library is intended to provide an API for talking to various devices, some of which don't have open source drivers. Currently it's difficult to program for these devices because there is no standard, easily available API to use. Each vendor provides its own. There are a few other APIs available that attempt to wrap them, but they are by and large
C++-only.
Designed for a Windows environment, with *nix as an afterthought.
Fail to build unless you have dependencies in the right places, i.e., complete lack of a proper configure/build system.
Most importantly, designed in such a way that they often link directly to proprietary libs, making me almost 100% sure it would be impossible to get these APIs into Debian.
Therefore my end-goal is to build a very simple and straight-forward C API that has a chance in hell of making it into distros so that people can actually write programs for these devices with a simple apt-get.
My question is, how should I best design the library to be GPL-compatible and Debian-friendly, but still be able to call out to proprietary libs when necessary?
Ideally I'd like the user to be able to apt-get a program using this library, and then as long as the vendor's user-level driver is installed to the expected place, everything should work out of the box.
My concern is two-fold:
having dependencies on optional, proprietary libs means the binary distro of the library can't be compiled to dynamically link to these libs, since they may or may not be available.
the user should not have to install dependencies for devices he does not have, open or proprietary.
How do other packages handle this problem of linking to proprietary libs and having run-time weak dependencies? Is dlopen the right way to go for everything? Should I dlopen only the proprietary stuff? What are reasons why or cases when Debian might reject such a package?
Lastly, I realize this probably isn't the right forum for this question about Debian policy, so can anyone point to me a better place to ask this question?
Thanks.
I have no relationship to Debian and cannot speak about their policies. However, for your framework, this seems a reasonable approach:
Define a simple header file that expresses the functionality you need from these plugins
Create a useful GPL/LGPL/BSD plugin that uses that interface
Have your main program load that using libdl, as you mentioned (if your main program is GPL, you need to have a licence exception to allow linking proprietary plugins)
Submit those for inclusion in Debian, and don't mention about the proprietary stuff
The main point is that your plugin system should be useful for free software, and not just be a Trojan horse to allow proprietary code to be loaded.
Using dlopen does not change the fact that you are writing a program to deliberately link to proprietary libraries and GPL libraries at the same time, it just shifts the linking from compile time to run time. While common consensus among the masses is that the GPL does not cover linking dynamically at runtime in this way, it is not safe legal advice to rely on such common understanding. The way I would solve the problem is to write a program with a single generic API for plugins (which can use dlopen, but the key is that you have not specifically written this program to link to proprietary libraries). The program must be under a free license that is compatible with all the plugins you eventually want it to be used with (ie LGPL, or GPL with exception for that API). Then write separate plugins for the GPL libraries and the proprietary libraries, and distribute them separately. If only one plugin can be loaded at a time, then there is no legal problem. If it is necessary to allow more than one plugin at once, then you need to be careful to separate your distribution. As the GPL is a distribution license, what the end users do is not a concern.