Re: [wxhaskell-users] wxHaskell windows binary missing dependencies

[Claus R. <cla...@ta...>]

> I agree with Claus that there is a potential problem here, although it
> is perhaps overstated slightly. However, as someone who works at a
> company which is very careful about IP issues, I understand the point.

For all I know, the license note for the vcredist_x86.exe redistributable
package could be an error on the Microsoft site - it doesn't appear (at
least not in such a prominent place) for earlier versions, and why would
they want to keep customers of their VS developers from using the C++
runtime libraries required? But if you want to rely on that, you'd need
to ask MS for clarification.

After all, it is not just a question for wxhaskell developers, but for the
users of the applications they develop, right? If only VS users have the
right to redistribute the runtime libs, and they fail to do so when building
the binaries, then noone down the line can use these binaries.

Eric elided some of the MSDN links I dug up when first asking my
question, see

http://www.mail-archive.com/wxh...@li.../msg00629.html

I'm not an MS developer, but it seems to me that it should be possible
simply to include the dlls in question with the wxhaskell binary, without
changing whatever build process you've set up, and without running into
license issues. In fact, the deployment examples explicitly discuss
redistribution of VC90.CRT, as an alternative to relying on vcredist_x86.exe.

As for cygwin/mingw builds: the instructions state that they need an
*older* make than the one required for ghc builds, which makes me
reluctant to try myself.

Given how often this has popped up even before the license note was
added, it would seem important to solve this at the source, once and
for all.

Anyway, good to see that wxhaskell has not gone dead again.

Claus

> There are a couple of approaches we could take.
>
> One is to build wxWidgets as a completely static library, and statically
> link with wxC. If we do this, we could continue to deliver binaries
> built using the Microsoft toolchain, although wxHaskell binaries would
> then be enormous (and I should note that Microsoft now goes to some
> trouble to make it tedious to statically link the run-time).
>
> I think, therefore, that the best approach is probably to deliver our
> Windows binary builds based on the MinGW toolset. I've never actually
> used this on Windows (I'm very familiar with the GNU toolset on Linux
> and other unices), and I suspect that this may be the case for the other
> developers. This means a transition for me, which I'm quite happy to
> make in theory, but which will probably take some time for to complete
> in practice.
>
> A handy benefit of using MinGW is that we would no longer suffer from
> 'Manifest hell' - the exciting new scenario Microsoft has produced to
> replace DLL hell...
>
> One thing to note is that I would like to be very certain that any
> change to the binary distribution model does not introduce a dependency
> on cygwin.dll for wxHaskell applications on Windows, since this would
> effectively require all apps based on our binaries to be GPL licensed,
> which I find unacceptable.
>
> Regards
> Jeremy
>
> Eric Kow wrote:
>> Hi Shelarcy,
>>
>> Is this something you know what to do with?  Perhaps the non-VS build
>> should be the default?
>>
>> Thanks!
>>
>> On Mon, Jun 29, 2009 at 09:35:33 +0100, Claus Reinke wrote:
>>
>>> "Claus Reinke" <cla...@ta...> wrote in message
>>> news:h103ak$aep$1...@ge......
>>>
>>>> I tried updating some old wxHaskell code to work with recent
>>>> ghc/wxHaskell. On a windows xp system, I have installed the
>>>> ghc-6.10.3 and wxhaskell-bin-msw2.8.10-ghc6.10.3-0.11.1.2-0
>>>> binary installers. After compiling my code, I can't run the executables,
>>>> due to missing dependencies (copied from event viewer):
>>>>
>>>>    Dependent Assembly Microsoft.VC90.CRT could not be found
>>>>    and Last Error was The referenced assembly is not installed on your system.
>>>>
>>
>> ...
>>
>>
>>>> This has come up before, and the advice has been to install extra bits
>>>> of Visual Studio. However, the latest recommended version of these
>>>> files clearly states that they may only be used with a valid Visual Studio
>>>> license:
>>>>
>>
>>
>>>> http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en
>>>>
>>>> So that is a no-go. As I understand the VS deployment models, VS
>>>> distinguishes between components that may be redistributed and those
>>>> that may not. wxHaskell should only depend on the former, and should
>>>> include them in the binary installer, because the kind person building
>>>> wxHaskell via VS is the only one who can include those redistributable
>>>> dependencies.
>>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> wxhaskell-users mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>>
>
>
> ------------------------------------------------------------------------------