search

emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler
Other
25.75k stars 3.3k forks source link

OS X problems #9

Closed kripken closed 13 years ago

kripken commented 13 years ago

Apparently we fail lots of tests (but not all) on OS X. I suspect header differences.

Errors have been reported in dlmalloc, libcxx, debug and freetype.

(I don't have an OS X machine to test on myself - need help with this.)

maxm commented 13 years ago

I started looking into the tests that fail in OSX. test_assert was easy to fix, the OSX libc headers use a function called __assert_rtn to handle an assert, instead of __assert_fail like glibc.

Then I tried to fix test_dlmalloc, but that opened a lot more problems. OSX's libc headers fail if no architecture is defined (i386 or x86_64), and defining one of those opens a lot more problems.

I ended up copying glibc headers from a Linux install and using that. I still have some tests failing, but it's a lot better. Maybe the best solution would be for emscripten to include a set of libc headers known to work? Trying to support whatever libc is installed on the system seems to be a dead end.

kripken commented 13 years ago

Interesting, thanks for the info. I like the idea of including a standard set of headers, it sounds like that can help a lot here. But that's assuming that does fix the issue everywhere - you say you are still seeing test failures, how bad are they?

Assuming that is fixable, and if we do want to go in the direction of including some standard headers, we then need to pick which ones. glibc and newlib are probably the main options.

maxm commented 13 years ago

I just did a quick check of the rest of the tests that are failing:

The last two tests problems are similar to the original libc problem. The rest seem to be unrelated.

kripken commented 13 years ago

It looks like there are some serious problems left. Mainly I am concerned about test_libcxx and test_pystruct.

One possible problem is that even with bundled libc headers, the compiler will still end up including system headers (in particular stuff like /sys and /bits can be very system specific). So to be completely independent of the underlying system, we would need to bundle an entire system include directory, basically an entire build environment like for a cross-compiler.

I suspect if we did that all these problems would be solved, I'm not very familiar with cross-compilation though so not sure how easy it would be.

snowyu commented 13 years ago

I've got the same problems on the MacOS.

Why not use the ll files directly instead of llvm-dis from object files?

Maybe write a tools to translate the libraries into ll files. And put these files into the folder: libs/c/xxx.ll

kripken commented 13 years ago

We could pregenerate .ll files I guess. We already have bundled .ll files for the python and lua tests (to save time building them).

But even if it would help you run more automatic tests without running a compiler, you still wouldn't be able to do much with emscripten unless you have another way of generating .ll from your source files. So not sure I understand what this gets us.

snowyu commented 13 years ago

Yes, we could. But we also need each c/c++ file has a corresponding ll file in a library. And we can know the source from the ll file. So we can reuse these ll files, only include the necessary ll files ..

kripken commented 13 years ago

I don't quite understand what you mean. What are you trying to achieve, and how?

snowyu commented 13 years ago

OK ,just for example:

$>clang funcs.c -emit-llvm -o./mylib/funcs.ll
$>clang funcs2.c -emit-llvm -o./mylib/funcs2.ll
$>clang main.c -emit-llvm
$>emscripten.py main.ll -I./mylib -ILibs/c/stdlibs
kripken commented 13 years ago

Emscripten now uses bundled headers, so building on OS X should be identical to Linux and everywhere else.

Closing this issue for now, please reopen if there are any remaining OS X problems.