Switching (back) to MSVC (Re: [Vm-dev] What generates disabledPlugins.c?0

[Geoffroy Couprie]

On Thu, Jul 22, 2010 at 9:59 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Thu, Jul 22, 2010 at 11:55 AM, Geoffroy Couprie <geo.couprie at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>>
>>> Hi Geoffroy,
>>>
>>> On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie <
>>> geo.couprie at gmail.com> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab <andreas.raab at gmx.de>wrote:
>>>>
>>>>>
>>>>> On 7/22/2010 4:55 AM, David T. Lewis wrote:
>>>>>
>>>>>> On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
>>>>>>
>>>>>>> But the more serious issue is that the configure in VMMaker is only
>>>>>>> suitable
>>>>>>> for linux.  I guess that the right thing to do for FreeBSD is to run
>>>>>>> make in
>>>>>>> platforms/unix/config to generate a FreeBSD-specific configure.  But
>>>>>>> I'm out
>>>>>>> of my depth when it comes to autoconf.
>>>>>>>
>>>>>>
>>>>>> Note that Ian moved to CMake for the unix builds, so autoconf is no
>>>>>> longer
>>>>>> used for building from the SVN trunk. In addition, Geoffroy Couprie
>>>>>> has
>>>>>> developed this further such that the VM can be built for both unix and
>>>>>> Windows targets, see thread here:
>>>>>>
>>>>>>
>>>>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
>>>>>>
>>>>>> It's up to Ian and Andreas to say if they want to pursue this
>>>>>> direction,
>>>>>> but if you need the Cog build process to be more platform independent
>>>>>> this would be a good thing to consider.
>>>>>>
>>>>>
>>>>> Personally, I'll be moving the Windows build back into MS land. All the
>>>>> reasons for using the MingW/GCC tool chain are gone by now:
>>>>> * Availability of the tool chain: There have been free versions of MSVC
>>>>> for years now, so this is no longer an issue.
>>>>
>>>> * Performance of the VM: With the JIT, the performance difference
>>>>> between the compilers no longer matters.
>>>>> * Size of difficulty of the install: New versions of MingW are no
>>>>> easier to install than Cygwin or other monsters.
>>>>>
>>>>
>>>
>>>> MSYS is not that hard to install. And GCC can be use to cross compile,
>>>> which is really useful for tests, continuous integration, etc.
>>>>
>>>
>>> What about C++ compilation?
>>>
>>
>> I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had
>> broken exception handling, and 4.4 works well.
>>
>
> The issue is that binaries produced with g++ -mno-cygwin -mwindows will not
> work because there is no support for them in the MS run-time.
>

Well, now, g++ produces working binaries.


>
>
>>>
>>>>
>>>>> * Consistent use of runtime libraries: For some external linkage,
>>>>> having the latest MSVC platform libraries available is important.
>>>>>
>>>>> At this point the advantage is clearly with the MS tool chain and the
>>>>> only hurdle is that I'll have to update all the makefiles etc.
>>>>>
>>>>  Well, here goes my shameless advertisement: CMake could be used to
>>>> generate Makefiles for MSVC :)
>>>> I think it would still need to be fixed though, but that's less work to
>>>> do.
>>>>
>>>> Anyway, do you think you could keep the code compatible with GCC? I
>>>> could take care of the header fixes.
>>>>
>>>
>>> Yes.  Its just a matter of ifdeffing, and the differences can be
>>> localized.  There are differences anyway.  Since MingW uses the MS libraries
>>> a few choice MS incompatibilities surface such as printf format specifiers
>>> for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x
>>> %I64d etc.  Hence
>>>
>>> #if _MSC_VER
>>> # define LLFMT "I64d"
>>> #else
>>> # define LLFMT "lld"
>>> #endif
>>>
>>> Yes, THAT is really annoying. We encountered a lot of problems with 32/64
>> code and format specifiers in vlc, but switching to gcc 4.4 fixed them.
>>
>
> How does 4.4 fix the issue?  Remember we're talking about -mno-cygwin
> -mwindows because under that environment there's no GPL issue.
>
Sorry, I was confusing with something else. We redefined the symbols too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100723/2ce41c46/attachment-0001.htm