mingw, cross-compilation, gcc

2
votes

Some context:

  • My program uses libary libfl.a (flex library). I compile it under linux:

    gcc lex.yy.c -lfl

  • I have mingw compiler installed i586-mingw32msvc-gcc (simple 'hello world' stuff compiles without problem)

  • I use ubuntu (probably does not matter)

  • I want to compile under linux for windows (produce binary .exe file which would be usable on windows)

My problem and questions:

When I try compiling my program

i586-mingw32msvc-gcc lex.yy.c -lfl

I get errors:

[...] undefined reference to '_yywrap' 
[...] undefined reference to '_WinMain@16'
  1. Do I understand correctly that I have to compile the content of libfl.a also with i586-mingw32msvc-gcc to be able to use it in this cross-compilation?
  2. In the source code there is function yywrap(), but not _yywrap(). Why I get error for function with underscore _?
  3. Whats up with the _WinMain@16? (no usage in source code)

My goal would be to understand what is happening here. If I get it to work, then its bonus points :)

Any help is appreciated

1
gccmingwflex-lexer

1 Answers

2
votes
  1. Yes, certainly. And here's why:
  2. C++ encodes additional semantic information about functions such as namespace/class affinity, parameter types etc. in the function name (that is called name mangling). Thus C++ library names are somewhat different from what you see in the source code. And each compiler does it in it's own way, that's why generally you're unable to link against C++ functions (C function names don't get mangled still) of a library built with a different compiler.
  3. Judging to mangling style, the undefined symbols are brought in by the Microsoft C++ compiler. I don't know exactly about why it needs WinMain, but after you recompile the libs with it, all these errors likely will be gone. And yes: maybe the WinMain() thing rises from msvc using it instead of main(), which presence is obligatory for a well-formed program? ;)