Building SWI-Prolog for Windows with VC9

[Degski]

I've been trying un-successfully to build swi-prolog 5.7.15 for windows with VC9. At the step of compiling init.pl into boot32.prc, plcon crashes on exit (something with fclose(fd) == EOF). Using Windows 2000 & VC6 works to a certain extent, but not fully... in addition, VC6 is no longer available and can only be obtained from "alternative" sources (the service packs can no longer be downloaded from MS either). Why not use the Intel compiler, firstly it is free for linux users :-)), and for windows a 30-day evaluation copy can be obtained from Intel. This compiler is (depending on the system of course) orders of magnitude faster than VC9 (and anything below it of course). Yes, I read the comment that one should use the binaries supplied... but I would like to be able to compile the source myself for my machine... making the most of it's multicores and advanced instruction set... An optimised version of gmp improves performance as well... I would equally like to use hoard (http://www.hoard.org/) as a (said better additional) memory allocator (claims to work well and improve pthread performance)!

 

"As of the integrated XPCE/SWI-Prolog 4.0.0, the installation is no longer based on MSVC project files that are simply too hard to maintain if building involves many custom steps. Instead, there are makefiles for NMAKE that run from a command window.": I don't see this really, using projects would be far more clear to the average Joe than the current nmake "......." and pre/post build and pre-link events can be included without a problem... I've created projects for upto and including building plcon.exe...

 

Is there anybody on this list that has been able to compile swi-pl successfully with VC9 (and how of course)?

 

 

 

[Jan Wielemaker-3]

On Wednesday 30 September 2009 12:40:33 pm Degski wrote:

> I've been trying un-successfully to build swi-prolog 5.7.15 for windows
> with VC9. At the step of compiling init.pl into boot32.prc, plcon crashes
> on exit (something with fclose(fd) == EOF). Using Windows 2000 & VC6 works
> to a certain extent, but not fully... in addition, VC6 is no longer
> available and can only be obtained from "alternative" sources (the service
> packs can no longer be downloaded from MS either). Why not use the Intel
> compiler, firstly it is free for linux users :-)), and for windows a 30-day
> evaluation copy can be obtained from Intel. This compiler is (depending on
> the system of course) orders of magnitude faster than VC9 (and anything
> below it of course). Yes, I read the comment that one should use the
> binaries
> supplied... but I would like to be able to compile the source myself for my
> machine... making the most of it's multicores and advanced instruction
> set... An optimised version of gmp improves performance as well... I would
> equally like to use hoard (http://www.hoard.org/) as a (said better
> additional) memory allocator (claims to work well and improve pthread
> performance)!

That is a lot of issues :-). I can't comment on VC9. It compiles with
VC6 and VS2005 (not sure how all these MS versions relate). Indeed, I
plan to drop MS/VC/whatever they name it. My current plan is to replace
it with MinGW. The main motivation would be to share most of the
Makefiles, so I need to maintain only one build configuration. Using the
same shell also simplifies things. And, MinGW is really free, not just
$0. I don't know whether or not such a move will make it easier to use
the Intel compiler as alternative. I guess that is likely.

My ideal would be if I can do the compilation using Wine.  Setting
up cross-compilation is an alternative, but complicated due to all the
steps that run Prolog.  Besides, you can't run the test-suite if you
cross-compile :-(

GMP installation gets a lot simpler when moving to MinGW.  That alone
almost justifies the move.

The hoard won't help too much because most of SWI-Prolog uses malloc()
for big chunks. The rest of the memory management is done by SWI-Prolog
itself. Besides, hoard is GPL and thus effectively changes SWI-Prolog
from LGPL to GPL.

> "As of the integrated XPCE/SWI-Prolog 4.0.0, the installation is no longer
> based on MSVC project files that are simply too hard to maintain if
> building involves many custom steps. Instead, there are makefiles for NMAKE
> that run from a command window.": I don't see this really, using projects
> would be far more clear to the average Joe than the current nmake "......."
> and pre/post build and pre-link events can be included without a problem...
> I've created projects for upto and including building plcon.exe...

The core system is just one step. Than we have all the packages and
their relations. Most important, I develop in Linux. Using nmake files I
can make the same change quite easily in both Makefile.in and
Makefile.mak. Otherwise I need to boot Windows, load the project, make
the change, etc.

The average Joe won't compile SWI-Prolog anyway, so I use what is most
practical for me and doable with some effort for those who insist.

> Is there anybody on this list that has been able to compile swi-pl
> successfully with VC9 (and how of course)?

You could try to drop the optimizer and see whether that helps. Note
that SWI-Prolog still needs -fno-strict-aliasing in GCC. Maybe VC9 uses
the same optimizations? Would be nice to get rid of that. I once tried
but failed to find all problems.

        Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Jan Wielemaker-3]

Hi Degski,

On Wednesday 30 September 2009 03:47:58 pm Degski wrote:
> > That is a lot of issues :-). I can't comment on VC9. It compiles with
> > VC6 and VS2005 (not sure how all these MS versions relate).
>
> The problem is, I probably gave the wrong impression, not in the nmake
> approach, that
> works fine, just like under VC6... There are some code problems... data
> types it seems...

I didn't expect nmake to be the problem :-)

> > Indeed, I plan to drop MS/VC/whatever they name it. My current plan is to
> > replace
> > it with MinGW. The main motivation would be to share most of the
> > Makefiles, so I need to maintain only one build configuration. Using the
> > same shell also simplifies things.
>
> I understand that... Will that provide for 64bit as well?

In my understanding it should work reasonable these days. I considered
moving from MSVC6 to MinGW before, but just at that time we decided to
support Win64 and MinGW-64 didn't exist. Does anybody have up-to-date
info?

> > And, MinGW is really free, not just $0.
>
> Isn't that just semantics?

Isn't semantics the most important thing? :-) Anyway, depending on a
compiler for which there is only a free evaluation version is not the
way I'd like to go. On the other hand, if someone sends me a free copy
of a compiler that produces much faster code, I'm happy to use it for
producing the official binaries (not on short notice; too busy now).

Pro MinGW: The code-base is optimized for GCC (also using GCC extensions
if it can). Con: its always better to compile your code using multiple
compilers ...

> There are in the log of libpl.dll these warnings:
>
> 9>..\..\src\pl-nt.c(90) : warning C4133: 'function' : incompatible types -
> from 'char [1024]' to 'LPCWSTR'

Looks like you compiled with UNICODE support enabled? Don't. The code
base is meant to be compiled as ANSI. It calls *W() functions where
needed to provide Unicode support at the Prolog level. That is a bit of
history from the path to introduce Unicode as well as maintaining
compatibility with the general multibyte character based approach on
POSIX systems. On Windows, the kernel thinks Windows is UTF-8 based
and wrapper functions call the *W() functions where needed.

> I think that one would be better of compiling GMP for the correct processor
> using
> the Intel Compiler, which auto parallelizes/vectorizes, using the generic
> c-code,
> instead of using the assembler versions...

I'd be interested to see the differences.

> Windows users could just link against MPIR (split-off from GMP, people
> unhappy
> with the "I only love linux approach")...

GMP on Windows is indeed a nightmare ...  I'll consider that when I decide
to change the build process on Windows.

> > Because Hoard avoids false sharing, Hoard also speeds up programs that
> > only occasionally call heap
> > functions but access these objects frequently.

Interesting.

> ..\..\bin\plcon.exe -O -o ..\..\boot32.prc -b ..\..\boot/init.pl
>
> This crashes on exit (the boot32.prc gets created), and points to build.c,
> line 229, as the culprit... :
>
> if ( fclose(fd) == EOF )
>
> Could this have something to do with the above warnings?

It might have something to do with UNICODE compilation.

> It would be nice though if you could have a look on how compilation (with
> nmake)
> goes using VC8 or VC9... Should'nt it be possible for you to check that
> using
> the free (as in 0$) Visual Studio Express 2008?

The Win64 build process uses the VS2005 toolchain. Maybe someone can try
to tweak that to compile Win32 using VC8/9. I'm happy to receive patches
for that, but I won't touch my virtual Windows box until I decide to
create a completely new setup for building the Windows version. I'm not
in a hurry, but if someone does it for me, I'd be glad.

> > The average Joe won't compile SWI-Prolog anyway, so I use what is most
> > practical for me and doable with some effort for those who insist.
>
> Isn't that partially because of the way it works, one has to by accident
> have
> a copy of VC6 laying around, which won't compile very well on anything
> other
>
> than a dedicated system (with all software about as old as VC6 itself) ,
> since
> it seems that otherwise, having installed VC8/9 runtimes, the various
> c-runtimes get mixed up...

Thats what I use. Windows XP in a VMWARE virtual machine with VC6 on it
and nothing else ...

> > > Is there anybody on this list that has been able to compile swi-pl
> > > successfully with VC9 (and how of course)?
> >
> > You could try to drop the optimizer and see whether that helps. Note
> > that SWI-Prolog still needs -fno-strict-aliasing in GCC. Maybe VC9 uses
> > the same optimizations? Would be nice to get rid of that. I once tried
> > but failed to find all problems.
>
> I'll definetely give that a try!
>
> I would like to conclude by saying that I don't hope you get me wrong, I
> love Prolog, in particular SWI-Prolog... I would be very happy to maintain
> a project based version for you (like the mac version) and the rest of the
> community, once the initial problems are ironed out...

No worries. I wouldn't do that. I make changes to the Makefiles quite
regularly and you'll have to find out what changed and how to get it
into the project files. Why bother? The Mac version uses the standard
toolchain. It only needs a few environment variables to work around some
version and location issues.

> PS: I'll soon get back to you on the plfann thing, did you have a look at
> it?

plfann??  Gues I missed something.  Typically you should consider me
stateless; there are too many discussions going on ...

        Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Matt Lilley-2]

I can weigh in a little on MinGW...

>>> Indeed, I plan to drop MS/VC/whatever they name it. My current plan is to
>>> replace
>>> it with MinGW. The main motivation would be to share most of the
>>> Makefiles, so I need to maintain only one build configuration. Using the
>>> same shell also simplifies things.
>>>      
>> I understand that... Will that provide for 64bit as well?
>>    
>
> In my understanding it should work reasonable these days. I considered
> moving from MSVC6 to MinGW before, but just at that time we decided to
> support Win64 and MinGW-64 didn't exist. Does anybody have up-to-date
> info?
>  

Yep, we've been using MinGW-64 for some time now - in fact we use it for
everything *except* compiling SWI :-) There are no serious issues that
I'm aware of, at least with the version we're using. There was a problem
with a much earlier version where in some cases DLLs were created with
invalid headers (I'm guessing something wasn't updated to be 64 bits
wide...)

>  
>>> And, MinGW is really free, not just $0.
>>>      
>> Isn't that just semantics?
>>    
>
> Isn't semantics the most important thing? :-) Anyway, depending on a
> compiler for which there is only a free evaluation version is not the
> way I'd like to go. On the other hand, if someone sends me a free copy
> of a compiler that produces much faster code, I'm happy to use it for
> producing the official binaries (not on short notice; too busy now).
>
> Pro MinGW: The code-base is optimized for GCC (also using GCC extensions
> if it can). Con: its always better to compile your code using multiple
> compilers ...
>  

Only if compiling it in multiple compilers will indicate actual
problems. Our experience with Microsoft's compilers is that they are
unpredicatable and often incorrect, and when either happens you're
simply stuck. Even if you had to pay the same dollar value to use GCC,
it would still be much 'freer', in the sense that such problems can be
resolved if you desire it strongly enough!


--
_____________________________________________
Matt Lilley
Software Engineer
SecuritEase

Tel:    [phone]
Fax:    [phone]
E-mail: matt.lilley@...
Web:    http://www.securitease.com
_____________________________________________

This e-mail has passed our content security scan.
It is covered by the confidentiality clauses at http://www.securitease.com/content_and_confidentiality

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog