Compiling with MSVC++ 2008 (was Re: [Link Grammar] Revisit regex.h problems w/MS compilers)
Borislav Iordanov
It turned out it wasn't hard to compile the latest LG code with MSVC++
2008 (a.k.a. MSVC9). Here are the steps to compile the current
codebase with it:
1) Get latest code from SVN.
2) rename link-grammar/link-features.h.in to link-features.h
3) Get the binaries from
http://gnuwin32.sourceforge.net/packages/regex.htm and unzip them in
directory REGEX somewhere on your computer.
4) Start MSVC++ 2008 and open the solution from the msvc9 folder.
5) Remove the jni-client.c file from the LinkGrammar project sources.
6) Open the command-line.c file and comment out the very first include
of strings.h
7) Open spellcheck.h and add the line "#include
<link-grammar/utilities.h>" at the top.
8) Open the build-disjuncts.c file and replace line 227 (the one
calling the fmaxf function) with the following:
c->maxcost = c3->maxcost == 0x7fc00000? c4->maxcost :
(c4->maxcost == 0x7fc00000? c3->maxcost : max(c3->maxcost, c4->maxcost));
9) Open the LinkGrammar project properties, then:
a) Under C/C++->General, add the REGEX/include in the "Additional
Include Directories". Mine reads "D:\lib\regex\include;..\."
b) Under Linker->General, add REGEX/lib in the "Additional Library
Directories". Mine reads D:\lib\regex\lib
c) Under Linker->Input, add regex.lib in "Additional Dependencies".
If you get the release tarball, step (2) is unnecessary.
To build the link grammar executable, create a "console" project, add
all source files, then make sure all the options are the same as the
DLL project, and it will build. I did that, and tested it, works fine.
I will update the project files and email them to Linas for SVN
commit. We also need to make some compatibility changes in the code to
remove those steps. Here are some notes on the steps above:
(3) The binary distribution of gunwin32 regex is a DLL. This means
that link-grammar needs to link with the .lib (for the DLL imports)
and then the regex.dll must be in the PATH when running the executable
or the link-grammar.dll.
(5) jni-client.c has no place in the linkgrammar project, I will
remove it permanently from there.
(6) The inclusion of strings.h in that file must be made conditional
upon a _MSC_VER define. The functions from strings.h that are being
used are defined in utilities.h under that define.
(7) MSVC9 doesn't implement the C99 standard and in particular it
doesn't support inline functions. The keyword "inline" is #defined as
empty "" string in utilities.h
(8) fmaxf is a C99 function, not available in MSVC. It seems that the
main difference with regular max is that it handles NAN floats. I
found the exact value of NAN to be 0x7fc00000 from a relatively
unreliable source:
http://www.linuxquestions.org/questions/programming-9/c-language-inf-and-nan-437323/
I'm not sure what would be the cross-platform replacement. This seems
to be IEEE standard, so it looks like that's what it is.
(9) I would suggest again that we check the gnuwin32 regex dependency
into SVN to make Windows' user life easier. It's a really small
library, not much disk storage, not much bandwidth.
Boris
Bruce Wilcox
> c) Under Linker->Input, add regex.lib in "Additional Dependencies".
this is already there from your sln file, so needs no separate addition.
>To build the link grammar executable, create a "console" project, add
>all source files, then make sure all the options are the same as the
>DLL project, and it will build. I did that, and tested it, works fine.
>I will update the project files and email them to Linas for SVN
>commit. We also need to make some compatibility changes in the code to
>remove those steps. Here are some notes on the steps above:
Will you be putting a console project in the SLN for distribution?
I got the project there in sln to build. Haven't yet built a separate
console project.
bruce wilcox
Borislav Iordanov
On Sat, Mar 27, 2010 at 6:45 PM, Bruce Wilcox <gowi...@gmail.com> wrote:
> Hi, Boris,
>
>> c) Under Linker->Input, add regex.lib in "Additional Dependencies".
>
> this is already there from your sln file, so needs no separate addition.
Right, those steps assumed one would be using the project&solution
files already in the tarball.
>> To build the link grammar executable, create a "console" project, add
>> all source files, then make sure all the options are the same as the
>> DLL project, and it will build. I did that, and tested it, works fine.
>> I will update the project files and email them to Linas for SVN
>> commit. We also need to make some compatibility changes in the code to
>> remove those steps. Here are some notes on the steps above:
>
> Will you be putting a console project in the SLN for distribution?
>
> I got the project there in sln to build. Haven't yet built a separate
> console project.
There should be a console project in the file I emailed to whole list.
Hopefully Linas will commit them and they will be available from svn
and incorporated in the next official build.
Best,
Boris
Bruce Wilcox
Hi, Boris.
So I see the projects linkparserexe and linkparser.
Though linkparserexe has all the parser c files and compiles them,
when I try to run it, it wants linkparser to be up to date. So I
fixed the properties so linkparser would compile. Then ran
linkparserexe project. It didn't know where the exe was, so I told
it. Then it complained it couldnt find regex2.dll , and there is no
such dll in the regex library.
There is a regex2.def and a regex.lib .
bruce
Bartosz Browarski
put your regex in. Just copy it next to the .exe you got by compiling
Boris' project and it'll find it.
2010/3/28, Bruce Wilcox <gowi...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "link-grammar" group.
> To post to this group, send email to link-g...@googlegroups.com.
> To unsubscribe from this group, send email to
> link-grammar...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/link-grammar?hl=en.
>
>
--
Wysłane z mojego urządzenia przenośnego
Bruce Wilcox
link-parser. Yeah!!!
bruce
Linas Vepstas
6) Open the command-line.c file and comment out the very first include
of strings.h
(6) The inclusion of strings.h in that file must be made conditional
upon a _MSC_VER define. The functions from strings.h that are being
used are defined in utilities.h under that define.
I'd rather use the default strings.h provided by msvc9, than those
in utilities.h I'm guessing that the utilities.h version were added
for msvc6. Which functions were these, and is there a #define that
uniquely identifies msvc9?
(8) fmaxf is a C99 function, not available in MSVC.
is there an fmax in msvc ? I don't care about NaN handling, just
wanted to do float point compares. I want to move to a float-pt
cost system, long-term; the integer-based system has too many
limitations.
--linas
Borislav Iordanov
On Mon, Mar 29, 2010 at 11:40 AM, Linas Vepstas <linasv...@gmail.com> wrote:
>
>
> On 27 March 2010 09:32, Borislav Iordanov <borislav...@gmail.com>
> wrote:
>>
>> 6) Open the command-line.c file and comment out the very first include
>> of strings.h
>>
>> (6) The inclusion of strings.h in that file must be made conditional
>> upon a _MSC_VER define. The functions from strings.h that are being
>> used are defined in utilities.h under that define.
>
> I'd rather use the default strings.h provided by msvc9, than those
> in utilities.h I'm guessing that the utilities.h version were added
> for msvc6. Which functions were these, and is there a #define that
> uniquely identifies msvc9?
There's no strings.h in msvc9 either. From what I gather with Google
search, people simply re-implement those functions when they want
unix/windows portable code. See for example:
>> (8) fmaxf is a C99 function, not available in MSVC.
>
> is there an fmax in msvc ? I don't care about NaN handling, just
> wanted to do float point compares. I want to move to a float-pt
> cost system, long-term; the integer-based system has too many
> limitations.
Yes, fmax compiles with MSVC9.
Boris
Linas Vepstas
There's no strings.h in msvc9 either.
Thanks, I just removed it.
If I haven't forgotten anything, then I believe the current source from SVN should
build w/ msvc9 without any further modification.
--linas
Borislav Iordanov
Oops, sorry, no 'fmax', there's a 'max' macro and that's about it. I
did a clean checkout just to make sure, and it does compile a call to
'fmax', but the linker fails. So, leave the fmaxf macro in utilities.h
as you currently have it.
Also, did I mislead you into doing a:
#define inline ""
in utilities.h? It should be
#define inline
i.e. not the empty string C literal, but the actual empty string :)
Other than that it builds. People should only need to download
gun-regex-win32 and changes their project settings to point to it.
Boris
Simon Stuart
Also had to add the line:
#define inline
in spellcheck.h otherwise I get compile errors related to static inline functions.
Regards,
Simon
------Original Mail------
From: "Borislav Iordanov" <borislav...@gmail.com>
To: <link-g...@googlegroups.com>
Sent: Tue, 6 Apr 2010 21:05:51 -0400
Subject: Re: Compiling with MSVC++ 2008 (was Re: [Link Grammar] Revisit regex.h problems w/MS compilers)
--
You received this message because you are subscribed to the Google Groups "link-grammar" group.
To post to this group, send email to link-g...@googlegroups.com.
To unsubscribe from this group, send email to link-grammar...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/link-grammar?hl=en.
____________________________________________________________________________
E-Mail scanned by Kaspersky Antivirus (Up To Date)
Simon Stuart
I don't know if it's just me but LGP now builds in Debug configuration without issue with only the define inline modifications Borris mentioned, but when I try to build the Release configuration, I get linker errors:
1>regex-morph.obj : error LNK2019: unresolved external symbol __imp__regcomp referenced in function _compile_regexs
1>regex-morph.obj : error LNK2019: unresolved external symbol __imp__regexec referenced in function _match_regex
1>regex-morph.obj : error LNK2019: unresolved external symbol __imp__regfree referenced in function _free_regexs
Do you get this Borris? If not, any thoughs on what's going wrong?
Regards,
Simon
------Original Mail------
From: "Simon Stuart" <kra...@greycascade.com>
To: <link-g...@googlegroups.com>
Sent: Wed, 07 Apr 2010 09:14:50 +0100
Linas Vepstas
I don't know if it's just me but LGP now builds in Debug configuration without issue with only the define inline modifications Borris mentioned, but when I try to build the Release configuration, I get linker errors:
1>regex-morph.obj : error LNK2019: unresolved external symbol __imp__regcomp referenced in function _compile_regexs
1>regex-morph.obj : error LNK2019: unresolved external symbol __imp__regexec referenced in function _match_regex
1>regex-morph.obj : error LNK2019: unresolved external symbol __imp__regfree referenced in function _free_regexsDo you get this Borris? If not, any thoughs on what's going wrong?
Clearly, the specification for the regex libs is done only in the Debug target,
and not in the release target. I quick look at the contents of LinkGrammar.vcproj
reveals this to be the case.
I did some manual editing to fix this; please try a clean svn checkout and a clean build,
and verify that its now fixed.
--linas
Simon Stuart
Linas,
I shall try this as soon as possible and get back to you... I've been trying to avoid making custom alterations to the copy recieved from SVN in order to get a successfull build so that any test builds are using the same exactly fileset as everyone else.
I really do appreciate the apparent concerted effort taken recently to resolve once-and-for-all the build issues under Windows and MSVC++, and I'm fairly certain I'm not alone on that sentiment. For that, I'd like to say thanks to yourself, Mr. Borislav, and everyone else whom has contributed towards a permenant resolution to these issues. I'm fairly certain that once I retrieve the latest SVN and start the build, it'll complete properly.
The reason I asked about the linker errors I recieved under Release was because I wasn't certain whether I had somehow installed the debug-only files for the Regex library (I'm not even sure if there are "debug-only files" in the Regex library to be honest).
Anyway.... I'll let you know how it goes, and thanks again.
Regards,
Simon J Stuart
------Original Mail------
From: "Linas Vepstas" <linasv...@gmail.com>
To: <link-g...@googlegroups.com>
Sent: Wed, 7 Apr 2010 13:26:31 -0500
Subject: Re: Compiling with MSVC++ 2008 (was Re: [Link Grammar] Revisit regex.h problems w/MS compilers)
--
You received this message because you are subscribed to the Google Groups "link-grammar" group.
To post to this group, send email to link-g...@googlegroups.com.
To unsubscribe from this group, send email to link-grammar...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/link-grammar?hl=en.
Bruce Wilcox
What game does my friend play?
The system generates as its first linkage set;
Game.s Ss does.v
does.v Ou play.n-u
and annotates that object with
my Dmu play.n-u
friend.n AN play.n-u
If you ask the reversed question-- My friend does play what game
you get more or less what you'd expect (except it wants to discard the what):
friend.n Ss does.v
does.v I*d play.v
[what]
play.v Ou game.n-u
Linas Vepstas
On 7 April 2010 14:36, Bruce Wilcox <gowi...@gmail.com> wrote:
>
> for the input:
>
> What game does my friend play?
>
> The system generates as its first linkage set;
The correct linkage is the fourth one:
Press RETURN for the next linkage.
linkparser>
Linkage 4, cost vector = (UNUSED=0 DIS=1 AND=0 LEN=12)
+----------------------Xp---------------------+
| +------------Bsm-----------+ |
| | +--------I*d-------+ |
| | +----SIs---+ | |
+---Wq--+-Dmuw-+---Rw--+ +--Ds-+ | |
| | | | | | | |
LEFT-WALL what game.n-u does.v my friend.n play.v ?
Press RETURN for the next linkage.
You'll probably need to study the B, R and SI links to understand this.
SI is inverted subject-- "my friend" - SI - "does play" (subject and verb order inverted)
B is kind-of-like an "inverted object" -- "play" - B - "game" (object and verb order inverted)
The only problem with the above is that game is identified as a mass noun, when it should
be a count noun. This is fixed in the 6th linkage:
Press RETURN for the next linkage.
linkparser>
Linkage 6, cost vector = (UNUSED=0 DIS=2 AND=0 LEN=12)
+---------------------Xp--------------------+
| +-----------Bsm-----------+ |
| | +--------I*d-------+ |
| | +----SIs---+ | |
+---Wq--+-Ds*w+--Rw--+ +--Ds-+ | |
| | | | | | | |
LEFT-WALL what game.s does.v my friend.n play.v ?
Press RETURN for the next linkage.
--linas
Borislav Iordanov
I've fiddled a bit more with the MSVC9 project files (attached for
commit) to fix this and make it a bit easier. The new ones rely on
environment variables (or "user macros") for the gnu regex and java
locations. Specifically:
GNUREGEX must be pointing to an unzipped gnuwin32-regex distribution and
JAVA_HOME must be pointing to a locally installed JDK.
Those two can be set either as system environment variables (Windows
users are supposed to know how to do this :) or as MSVC9 user macros.
Of course, people are still free to just modify the project settings
and put the location values there.
Boris
> --
> You received this message because you are subscribed to the Google Groups
> "link-grammar" group.
> To post to this group, send email to link-g...@googlegroups.com.
> To unsubscribe from this group, send email to
> link-grammar...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/link-grammar?hl=en.
>
--
http://www.kobrix.com - HGDB graph database, Java Scripting IDE, NLP
http://kobrix.blogspot.com - news and rants
"Frozen brains tell no tales."
-- Buckethead
Simon Stuart
Borislav,
Glad to see you adopted my idea.... this makes it so much easier for everyone to maintain the most up-to-date SVN version of the source and compile without the necessity to make any custom modifications to the solution files (which would cause SVN to complain about conflicts when doing the next Synchronization).
For those who want to set up those locations as Windows Envrionment Variables here's a brief (but accurate) set of instructions. Keep in mind I'm doing this on Windows 7, though almost all steps correlate perfectly with Vista and XP (though some buttons/label links are actually Tabs under XP).
1) Start > Control Panel > System (remember in Vista or 7 you need to switch to "Classic View" or "Large icons" respectively to see the System icon)
2) "Advanced system settings" (or "Advanced" tab under XP)
3) On all versions you will see a button with the caption "Environment Variables", press it.... (ALL REMAINING STEPS CORRELATE ON XP, VISTA, AND 7)
4) You now see two lists of environment variables... the top one says "User variables for <yourusernamehere>" and is localized to your user account, the other says "System variables" and applies to ALL user accounts on that computer.
5) Press the "New ..." button corresponding to whether or not you want the variables to be valid on ALL accounts or just your own (either way the following steps remain the same)
6) In the "Variable name:" box, enter "GNUREGEX".
7) In the "Variable value" box, enter the path to your installation of GNUREGEX (on my system this is "C:\Program Files (x86)\GnuWin32" as I am on Windows 7 Ultimate x64) then press "OK"
8) Press the same "New ..." button and this time in the "Variable name" box enter "JAVA_HOME", and in the "Variable value" box enter the path to your Java SDK root folder. (IMPORTANT NOTE: On some systems this variable may already be defined automatically by the JAVA SDK installation! You should check the variables lists before creating a new one to avoid any conflict).
9) Press "OK" and close all Windows opened during the above steps.
If you were running MSVC++ or your chosen development environment whilst performing the above steps, you should restart it! Once restarted you should be able to build the latest version of the code as submitted by Mr. Borislav without ANY issues.
I hope this small but efficient guide to Environment Variables has been useful to you, and remember that virtually all Windows-compatible Open Source projects adopt the principal of Environment Variables for path localization. This is why I made the suggestion to Mr. Borislav to adopt this principal in his modifications to the LGP source.
Thank you Mr. Borislav for taking the time to make the build process under Windows so much easier for everyone, and the same to Linas. I'm sure this sentiment is shared by the rest of us Windows developers as now we don't have to resolve platform-specific issues manually any longer.
Regards,
Simon J Stuart
------Original Mail------
From: "Borislav Iordanov" <borislav...@gmail.com>
To: <link-g...@googlegroups.com>
Sent: Thu, 8 Apr 2010 23:55:08 -0400
Subject: Re: Compiling with MSVC++ 2008 (was Re: [Link Grammar] Revisit regex.h problems w/MS compilers)
Simon Stuart
I can confirm that using Borislav's latest project files for MSVC++ 2008, and following the steps provided in my Environment Variables guide, I was able to build the latest SVN source with only one change (renaming "link-features.h.in" to "link-features.h".... why exactly does it have the ".in" tagged to it by default?). Anyway, this is so much easier to deal with as I'm sure all other Windows developers will agree.... so I'd like to reiterate my previous "thanks".
Regards,
Simon J Stuart
------Original Mail------
From: "Simon Stuart" <kra...@greycascade.com>
To: <link-g...@googlegroups.com>
Sent: Fri, 09 Apr 2010 08:22:28 +0100
Subject: Re: Compiling with MSVC++ 2008 (was Re: [Link Grammar] Revisit regex.h problems w/MS compilers)
Borislav,
Glad to see you adopted my idea.... this makes it so much easier for everyone to maintain the most up-to-date SVN version of the source and compile without the necessity to make any custom modifications to the solution files (which would cause SVN to complain about conflicts when doing the next Synchronization).
For those who want to set up those locations as Windows Envrionment Variables here's a brief (but accurate) set of instructions. Keep in mind I'm doing this on Windows 7, though almost all steps correlate perfectly with Vista and XP (though some buttons/label links are actually Tabs under XP).
1) Start > Control Panel > System (remember in Vista or 7 you need to switch to "Classic View" or "Large icons" respectively to see the System icon)
2) "Advanced system settings" (or "Advanced" tab under XP)
3) On all versions you will see a button with the caption "Environment Variables", press it.... (ALL REMAINING STEPS CORRELATE ON XP, VISTA, AND 7)
4) You now see two lists of environment variables... the top one says "User variables for <yourusernamehere>" and is localized to your user account, the other says "System variables" and applies to ALL user accounts on that computer.
5) Press the "New ..." button corresponding to whether or not you want the variables to be valid on ALL accounts or just your own (either way the following steps remain the same)
6) In the "Variable name:" box, enter "GNUREGEX".
7) In the "Variable value" box, enter the path to your installation of GNUREGEX (on my system this is "C:Program Files (x86)GnuWin32" as I am on Windows 7 Ultimate x64) then press "OK"
Linas Vepstas
Hi Linas,
I've fiddled a bit more with the MSVC9 project files (attached for
commit)
I've applied these, and also Stuarts how-to instructions.
The only quibble/question I have is that it seems like the two files link-parser.c
and command-line.c are included in the library build; they should not be; they
belong to the executable.
Similarly, I notice that the executable does not seem to actually link to the
library that was created, but rather, respecifies all the source files again.
Neither of these much matter, unless one is a perfectionist.
I plan on releasing the next version, with these fixes, "real soon now".
--linas
Simon Stuart
Cheers Linas.
------Original Mail------
From: "Linas Vepstas" <linasv...@gmail.com>
To: <link-g...@googlegroups.com>
Sent: Fri, 9 Apr 2010 16:23:23 -0500
Subject: Re: Compiling with MSVC++ 2008 (was Re: [Link Grammar] Revisit regex.h problems w/MS compilers)
--
You received this message because you are subscribed to the Google Groups "link-grammar" group.
To post to this group, send email to link-g...@googlegroups.com.
To unsubscribe from this group, send email to link-grammar...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/link-grammar?hl=en.