%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?

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

@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.