Yes, I always use CMake when possible, but now I'm stuck trying to compile the latest FreeType. It does not use CMake and I couldn't find 3rd party CMake file for it on the net.
But I had the same problem with libpng and libjpeg. I'm using MSYS's bash to run configure, but it still messes up something. Namely, when I run emcc from console, it works just fine, but when it is run from configure, it complains about link.exe. I tried to put link.exe into PATH, but now I'm getting configure:2920: python c:\X\emscripten\emscripten\1.13.0\emcc conftest.c >&5 LINK : error LNK2001: unresolved external symbol mainCRTStartup which is unsurprising, because test program configure is trying to compile does not have WinMainand isn't linked with MSVC's standard libraries... Actually, maybe I'm just missing some params to configure? Like specifying host or target system type? What surprises me, is that FreeType (older 2.4.2 version) is one of the tests for Emscripten, so I guess there is a way to configure & compile it somehow? But I can't see how test suite is doing it. On Friday, April 18, 2014 11:53:53 PM UTC+4, jj wrote: > > I played around this a bit with zlib-1.2.8 library, and noticed the > following: > - invoking node.js with cygwin paths (/cygdrive/c/xxx) will fail, unless > one builds node under cygwin, or writes a shell script wrapper which > converts cygdrive paths in command line arguments to normal Windows paths. > There doesn't seem to be a node.js available for cygwin specifically. > - unix configure and makefiles and mingw32-make don't generally play > well together. mingw32-make is not capable to build makefiles that have > cygwin paths, even if you run mingw32-make under cygwin. It's best to try > to use either MSYS or cygwin make when configure scripts are in play. > - If the target library has a CMakeLists.txt file, that is better used > instead, since CMake is designed to support Windows-host+Emscripten-target > cross-compilation situations. Configure scripts are very primitive and > unix-specific, and not at all cross-platform. > - Wherever configure would invoke 'clang' or 'gcc' natively, in > Emscripten it should instead invoke 'emcc'. If this is not happening, then > it is probably an emconfigure bug, or an issue with too rudimentary a > configure script. > - Clang is hardcoded on Windows to invoke Visual Studio linker if one > tries to generate native executables with that. This is because Clang does > not implement its own linker. Emscripten never tries to link out native > executables, and therefore I'm not sure if configure scripts might have > something platform-specific for the configure step that is invoking clang > directly past emcc. If you see a command line invocation of 'emcc/em++ > xxxxxx' results in Visual Studio link.exe (or native GCC/MinGW > /usr/bin/link) being invoked, then that is an Emscripten bug. That is, > whenever emscripten invokes clang internally, it should never do so to link > out a native executable. > - As a hack, one can try removing /usr/bin/link from cygwin path, or add > visual studio link.exe before /usr/bin to path, to make VS linker visible > to cygwin environment for any native clang builds configure scripts might > try. > - The proper fix would be to develop configure scripts to understand > that it should not try to generate native executables, but instead it's > generating .js files which are run by calling 'node output.js'. This will > probably need platform-specific added information to the configure scripts > in question. > > If you have good automated repro steps (e.g. a .sh script that downloads a > library, unzips, configures and builds) for issues, feel free to report > them and we can have a look. > > Jukka > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
