%option c++ is not compatible with %option noyywrap - linker error: multiple definition

[lexxmark]

related to westes/flex#472

[lexxmark]

@ledaniel2 I don't see implementation of the yyFlexLexer::yywrap in the header file

winflexbison/flex/src/FlexLexer.h

Line 145 in 8063e9b

virtual int yywrap();

Why you get a link error?

How to reproduce your issue?

[ghost]

The definition is in the generated header and implementation file, admittedly the problem goes away if FlexLexer.h is used instead of the generated header (which I hadn't realized before), but in the more complex project I have this is not an option.

lexer_bug.l:

%option c++ noyywrap outfile="ScannerX.cpp" header="ScannerX.hpp"

%%

.	return 0;

main.c:

#include "ScannerX.hpp"

int main() {
    FlexLexer *lex = new yyFlexLexer;
    lex->yylex();
}

>win_flex --wincompat lexer_bug.l
>cl /EHsc /I. /Fetest.exe main.cpp ScannerX.cpp
[...]
Generating Code...
Microsoft (R) Incremental Linker Version 14.28.29334.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
main.obj
ScannerX.obj
ScannerX.obj : error LNK2005: "public: virtual int __thiscall yyFlexLexer::yywrap(void)" (?yywrap@yyFlexLexer@@UAEHXZ) already defined in main.obj
test.exe : fatal error LNK1169: one or more multiply defined symbols found

Both ScannerX.hpp and ScannerX.cpp contain: int yyFlexLexer::yywrap() { return 1; }

So to clarify, it's all of %option c++ noyywrap and header= which appear to be incompatible when using #include with the generated header. The offending line in winflexbison is flex\src\main.c:1774

[lexxmark]

I've added inline code to flex\src\main.c:1774 and now there is no link error.

The correct fix could be done in the upstream project.

[lexxmark]

@ledaniel2 please try this package https://ci.appveyor.com/api/buildjobs/5cibc2240rafovcs/artifacts/build%2Fwin_flex_bison-dev-2019-Win32-Release.zip

[ghost]

@lexxmark Thanks for that, I can confirm that it works with the test program here, also with my other project.

I'm happy for this issue to be closed here, however what a more correct fix for upstream would be I don't know. I'll continue to watch.