[Link Grammar] Re: Compiling with MSVC++ 2008
Borislav Iordanov
Here are the updated MSVC++ project files. They make references to my
local d:\lib\regex location, which people will need to modify - this
should be the only thing that needs modification and it's unavoidable
unless you decide that you want to include gnuwin32 regex in the LG
distribution.
The rest of the compilation issues are pretty easy to fix. See steps
(6), (7) and (8) below. Except for step (8) which I took some more
time to test and, of course, what I did won't work for several reasons
(the cast from long to float might not yield the NAN float value, plus
comparing anything to NAN will always return false). Actually it turns
out, MSVC has a _isnan function that does the job, so a Windows
version of fmaxf conditionally included in utilitities.h could look
like this:
float fmaxf_win(foat x, float y)
{
return _isnan(x) || y > x ? y : x;
}
That should be enough and pretty simple for Windows users. The MSVC++
2008 Express Edition compiler that I use is available for free.
Best,
Boris
On Sat, Mar 27, 2010 at 11:32 AM, Borislav Iordanov
<borislav...@gmail.com> wrote:
> Hi all,
>
> 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
>
--
http://www.kobrix.com - HGDB graph database, Java Scripting IDE, NLP
http://kobrix.blogspot.com - news and rants
"Frozen brains tell no tales."
-- Buckethead
Borislav Iordanov
Bottom line: besides the regex dependencies, all problems with msvc9
stem from the fact MS refused to implement the C99 standard. So every
C99 function that link-grammar uses must be ported somehow and
conditionally included in its codebase.
If somebody does the job of making link-grammar compatible with mingw,
that would be great too.
Boris
On Sat, Mar 27, 2010 at 12:19 PM, Borislav Iordanov
Richard
I installed MS C++ 2008 and incorporated all the steps in your
description (I think). I used the MSVC9 project files provided with LG
v2.6.6. I'm still left with the following link errors. Did I somehow
grab the wrong regex package?
api.obj : error LNK2019: unresolved external symbol _compile_regexs
referenced in function _dictionary_six
api.obj : error LNK2019: unresolved external symbol _read_regex_file
referenced in function _dictionary_six
api.obj : error LNK2019: unresolved external symbol _free_regexs
referenced in function _dictionary_delete
link-parser.obj : error LNK2019: unresolved external symbol
_lg_expand_disjunct_list referenced in function _main
tokenize.obj : error LNK2019: unresolved external symbol _match_regex
referenced in function boolean_reg_dict_lookup
Thanks for all your help!
On Mar 27, 11:29 am, Borislav Iordanov <borislav.iorda...@gmail.com>
wrote:
> >>http://gnuwin32.sourceforge.net/packages/regex.htmand unzip them in
> >>http://www.linuxquestions.org/questions/programming-9/c-language-inf-...
>
> >> 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
>
> > --
> >http://www.kobrix.com- HGDB graph database, Java Scripting IDE, NLP
> >http://kobrix.blogspot.com- news and rants
>
> > "Frozen brains tell no tales."
>
> > -- Buckethead
>
> --http://www.kobrix.com- HGDB graph database, Java Scripting IDE, NLPhttp://kobrix.blogspot.com- news and rants
>
> "Frozen brains tell no tales."
>
> -- Buckethead
>
> LinkGrammar.sln
> 2KViewDownload
>
> LinkGrammar.vcproj
> 12KViewDownload
>
> LinkGrammarExe.vcproj
> 9KViewDownload
>
> LinkGrammarJava.vcproj
> 5KViewDownload
Bartosz Browarski
my java project in Windows! And it even gives parsing results similar
to the console parser you provided, so it apparently works :p
Once again, thanks a lot. Obviously not all Linux-men are bad and
smelly (I've been told they are:p)
Regards
Brov
2010/3/27, Borislav Iordanov <borislav...@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
Borislav Iordanov
1) Make sure all *.c files in the link-grammar source folder are added
to the project and nothing else.
2) Make sure the folder containing regex.lib is in the "Additional
Library Directories" linker option (my first guess is that you have a
typo precisely there), then that regex.lib itself is listed as an
additional dependency.
Also, try the project files that I emailed.
Best,
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
Richard
There were indeed several c files missing from the project. I tried
the build again but that got me back to the error of the missing
"size_t" declaration. I manually inserted "typedef unsigned int
size_t;" just after "#include <sys/types.h>" in the regex.h file. I'm
only guessing that this was the correct typedef statement. I'll have
to search around to confirm this but at last I have a successful
build, but since the provided MSVC9 project built a .DLL I won't know
if everything works till I rewicker an executable similar to that of
the original Link41b package.
On my version of MS C++, typos for library pathnames return error
messages.
BTW, I didn't receive any email from you with the project files.
Poka, poka.
On Mar 27, 7:44 pm, Borislav Iordanov <borislav.iorda...@gmail.com>
wrote:
> >> >>http://gnuwin32.sourceforge.net/packages/regex.htmandunzip them in
> >> >http://www.kobrix.com-HGDB graph database, Java Scripting IDE, NLP
> >> >http://kobrix.blogspot.com-news and rants
>
> >> > "Frozen brains tell no tales."
>
> >> > -- Buckethead
>
> >> --http://www.kobrix.com-HGDB graph database, Java Scripting IDE, NLPhttp://kobrix.blogspot.com-news and rants
Borislav Iordanov
> Thanks again Boris,
>
> There were indeed several c files missing from the project. I tried
> the build again but that got me back to the error of the missing
> "size_t" declaration. I manually inserted "typedef unsigned int
> size_t;" just after "#include <sys/types.h>" in the regex.h file. I'm
As I mentioned you need to turn on "Detect 64-bit compatibility
issues" somewhere in the project settings (that yields a /Wp64
command-line option I believe).
> only guessing that this was the correct typedef statement. I'll have
> to search around to confirm this but at last I have a successful
> build, but since the provided MSVC9 project built a .DLL I won't know
> if everything works till I rewicker an executable similar to that of
> the original Link41b package.
You just need to create a console project with all the same source
files and settings.
> On my version of MS C++, typos for library pathnames return error
> messages.
>
> BTW, I didn't receive any email from you with the project files.
Hmm, I emailed to the whole list. Perhaps nobody got them?
Boris
Peter Szolovits
Bruce Wilcox
>
>Hmm, I emailed to the whole list. Perhaps nobody got them?
I got them.
bruce
Richard
following message.
cl : Command line warning D9035 : option 'Wp64' has been deprecated
and will be removed in a future release
So, if next month there's this "future release" will I have the size_t
problem?
I get the digest email version of the list maybe the attachments are
buried somewhere in the digest version.
On Mar 27, 10:07 pm, Borislav Iordanov <borislav.iorda...@gmail.com>
wrote:
Borislav Iordanov
> On the issue of "Detect 64-bit compatibility". With it on I get the
> following message.
>
> cl : Command line warning D9035 : option 'Wp64' has been deprecated
> and will be removed in a future release
>
> So, if next month there's this "future release" will I have the size_t
> problem?
:) I am not a Microsoft employee, but I'm sure we'll figure it out somehow...
#define-ing size_t conditionally as an MS compatibility like the C99
functions that are missing is of course also a good option.
Boris
Linas Vepstas
unless you decide that you want to include gnuwin32 regex in the LG
distribution.
I'm philosophically against this, for several reasons.
-- Users should not be downloading and compiling source code; they should be
downloading and installing pre-compiled binaries. These binaries should not be
coming from some random website, but should come from some standardized
repository that is widely used and trusted, and use some standardized system
that is widely understood. There are a variety of such standard installers for
Linux ("the distros"), and at least one for Mac ("Mac Ports") I'm unclear of what
the choices are for windows users, but whatever they are, someone should
lobby to get link-grammar (and regex) included in the most popular sites.
I would prefer to get bug reports and fixes from package maintainers who have
the technical expertise to perform the packaging properly, and can speak for
and represent hundreds of users, instead of random and semi-incoherent
individual reports.
-- Including foreign sources just magnifies the problems:
* If these don't compile, I catch shit
* If these are incompatible with other install libs that do the same thing, then
dll hell results.
* If there are bug fixes in the foreign source, then I have to track those. Esp.
troublesome if these are security fixes.
* Foreign sources make life considerably harder for the package maintainers.
Really, what is needed is that link-grammar needs a package maintainer for
Windows who can get it into the whatever package repositories are popular
with Windows users (tucows, or something like that?)
--linas
Linas Vepstas
Oops, I forgot the attachments...:)
These are now in svn.
Bottom line: besides the regex dependencies, all problems with msvc9
stem from the fact MS refused to implement the C99 standard. So every
C99 function that link-grammar uses must be ported somehow and
conditionally included in its codebase.
I believe that this is now the case, with some remaining confusion about strings.h
and size_t. I suspect that some/many of the string functions, and size_t, are
defined in the 64-bit msvc9, but are not in the 32-bit version, which would explain
some of the confusion. If this is the case, I can accommodate both, but would
need some #ifdef way of telling them apart.
--linas