building on windows

[Steven Caron]

Hey there

I am building SeExpr on windows and I am very close. I had to do a lot of things and used this as a guide...

http://takkun.nyamuuuu.net/blog2/archives/4769

anyways, I currently have a unresolved symbol error which I am totally confused about.

>SeExprParser.obj : error LNK2019: unresolved external symbol "int __cdecl SeExprlex_destroy(void)" (?SeExprlex_destroy@@YAHXZ) referenced in function "bool __cdecl SeExprParse(class SeExprNode * &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,int &,int &,class SeExpression const *,char const *,class std::vector<char *,class std::allocator<char *> > *)" (?SeExprParse@@YA_NAEAPEAVSeExprNode@@AEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEAH2PEBVSeExpression@@PEBDPEAV?$vector@PEADV?$allocator@PEAD@std@@@3@@Z)

1>E:\library\development\SeExpr\build\src\SeExpr\Release\SeExpr.dll : fatal error LNK1120: 1 unresolved externals

ideas? or anyone have a fork with improved windows build support?

Thanks

Steven

[Andrew Selle]

The hardest part about building on Windows SeExpr is the lack of bison/flex on standard windows machines. Those instructions that you link to change the substitution rules used for editing the lexer/parser function names. I think something there is not being done consistently. 

What I do when I build on Windows is to copy generated parser and lexer cpp files from a Linux machines i.e. after building on linux

seexpr-linux-src-dir/src/SeExpr/generated/* 

has files that can be copied to say

c:/seexpr-windows-src-dir/src/seexpr/generated/*

then you do 

c:

cd \seexpr-windows-src-dir

md build

cd build

cmake ..\

(and cmake should find the generated files without yacc being used)

Moreover, I have built win32 seexpr binaries built here:

http://aselle.github.io/binaries/index.html

I also have instructions on that page on how I build on Windows.

Also, I made source code changes to the mainline to fix some of the issues that the instructions in that other page have given.

Steven

--
You received this message because you are subscribed to the Google Groups "seexpr-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seexpr-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Steven Caron]

Thanks so much for the pre-built library. I will test adding this to my application soon.

I understand that the lack of bison/flex/sed on windows can be a problem, but I spent the time to get those installed so this should be doable entirely on a windows machine. I don't know the syntax/arguments for these applications so I can't be sure how those instructions are causing issues. I will take the time learn bison/flex/sed and see if I can make more suitable changes for windows support. I don't have access to a linux machine at this time, so I need to make it work on windows. 

If you could just clarify... are you convinced that the generated source files are the problem with that symbol error? its not a project setting?

and lastly, why not ship these generated files? at least on the tagged/stable releases?

Thanks for your help and open sourcing SeExpr.

Steven

[Steven Caron]

The single quotes around the arguments are causing issue...

1>Generating SeExprParserLex.cpp

1>sed: -e expression #1, char 1: unknown command: `''

Also bison complains about this...

1>E:/library/development/SeExpr/src/SeExpr/SeExprParser.y:193.6: warning: empty rule for typed nonterminal, and no action

1>conflicts: 29 shift/reduce, 3 reduce/reduce

1>E:/library/development/SeExpr/src/SeExpr/SeExprParser.y:193.6: warning: rule useless in parser due to conflicts: assign: /* empty */

So I edited the CMakeLists.txt removing the single quotes, I also removed > /dev/null and made it > null... otherwise cmd.exe complains about not being able to find this path. Now I still get the bison conflict warning, but its a warning so I am going to ignore for now.

2>Generating y.tab.c, y.tab.h

2>E:/library/development/SeExpr/src/SeExpr/SeExprParser.y:193.6: warning: empty rule for typed nonterminal, and no action

2>conflicts: 29 shift/reduce, 3 reduce/reduce

2>E:/library/development/SeExpr/src/SeExpr/SeExprParser.y:193.6: warning: rule useless in parser due to conflicts: assign: /* empty */

2>Generating SeExprParser.tab.h

2>Generating SeExprParserLexIn.cpp

2>Generating SeExprParserLex.cpp

2>Generating SeExprParser.cpp

2>Compiling...

2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64

But I still get a symbol error. Could we compare my generated files with ones you have generated?

Thanks

Steven 

[Marie Fétiveau]

Hello !

Steven, I get the same :  error LNK2019: unresolved external symbol "int __cdecl SeExprlex_destroy(void)" 

Did you find a solution ?

Building with msvc 10 on Windows 7 (64).

Thanks,

Marie

[Steven Caron]

it has been a while i would need to dig this back up but what are you building as? shared library or static library?

--
You received this message because you are subscribed to a topic in the Google Groups "seexpr-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/seexpr-discuss/TAsGkXIjiH4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to seexpr-discus...@googlegroups.com.

[Marie Fétiveau]

I get the error with both static and shared builds (but my final goal is static).

I don't have this error on Linux, so I did a quick comparaison and :

---> in the generated-on-linux SeExprParserLex.cpp, I find an implementation of SeExprlex_destroy that I don't find in the generated-on-windows same file.

Here's my Linux build.

Here's my windows build.

If I define a SeExprlex_destroy that do nothing, it builds, I can link the library and use it without visible problems.

But this isn't satisfying especially because this function may have some good reasons to "destroy", :p

[Colin Doncaster]

FWIW - I use the generated parser files from Linux during our Windows build of SeExpr vs. using any sort of Windows yacc/bison shenanigans.

You received this message because you are subscribed to the Google Groups "seexpr-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to seexpr-discus...@googlegroups.com.

[Steven Caron]

ya, if you have access to linux machine to generate those files... use them!

[Andrew Selle]

Yes. I have never really done a build on windows successfully with non-generated files. The annoyance of building on windows is driving me very strongly to wanting to rewrite the parser and scanner by hand using recursive descent to avoid that dependency. There are other annoyances of lex/yacc like threading.  Another strategy that may work is to install cygwin and do a unix/linux style build on windows with that and then copy the generated files out to your visual studio windows build.

-Andy

[Janet Berlin]

> and lastly, why not ship these generated files? at least on the tagged/stable releases?

I've added these pre-generated flex/bison files to a /windows7 subdirectory in the code base.  It's currently awaiting a pull request.

src/SeExpr/generated/SeExprParser.cpp
src/SeExpr/generated/SeExprParserLex.cpp
src/SeExpr/generated/SeExprParser.tab.h

src/SeExprEditor/generated/SeExprSpecParser.cpp
src/SeExprEditor/generated/SeExprSpecParserLex.cpp
src/SeExprEditor/generated/SeExprSpecParser.tab.h

Janet

On Sunday, May 5, 2013 12:53:38 PM UTC-7, Steven Caron wrote: