Özkan Sezer

Maybe @ericwa can help

> found [this page](https://gist.github.com/peterspackman/8cf73f7f12ba270aa8192d6911972fe8). For what it's worth, this is my toolchain file for cross-compilation purposes: ``` SET(CMAKE_SYSTEM_NAME Windows) SET(CMAKE_C_COMPILER /opt/cross_win64/bin/x86_64-w64-mingw32-gcc) SET(CMAKE_CXX_COMPILER /opt/cross_win64/bin/x86_64-w64-mingw32-g++) SET(CMAKE_RC_COMPILER /opt/cross_win64/bin/x86_64-w64-mingw32-windres) # where is the target...

Interestingly, the generated map file I get has no stray `\` characters on my linux. cmake version is 3.9.6, if that matters.

In any case, removal of escaping semicolons _should_ not hurt.

So, the following is a go? (I couldn't make it to emit the missing newline to end, though.) ```diff diff --git a/CMakeLists.txt b/CMakeLists.txt index 597efac..5bd290f 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt...

Off-topic to this ticket: would the existing wavpack cmake'ry work when embedding in other projects? I.e.: I might cook wavpack support to our SDL_mixer (hopefully soon (TM)).

> So @sezero , I assume this step passes in your setup? Well, I wasn't hitting any errors, because I was setting `BUILD_SHARED_LIBS=ON` Without that, I get the following error...

> One thing to note here: COMPILER_SUPPORTS_SYMBOL_MAPS needn't (shouldn't) be checked at all if we are not building a shared lib. I believe that should be rectified. Unless the existing...

> That sounds correct to me. @dbry: The patch is above, but if you want a PR I can create one.

> unless you want the credit... Nope, don't want or need it. > > Pascal calling convention is not happening correctly: > > ``` > /usr/bin/i686-w64-mingw32-ld: warning: resolving _CloseFilterInput by...