OS X problems

[kripken]

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]

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]

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]

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

• test_freetype, test_openjpeg and test_the_bullet are failing to build the libraries. The configure fails when checking the compiler (which is set to emmaken.py).
• test_libcxx is failing to run with error: Assertion failed: Must have a history for a safe heap load!
• test_pystruct is failing when compiling the .ll into Javascript. The error is:
  // Unclear type in struct: x86_fp80, in %union.PyGC_Head
  Assertion failed: undefined
  Stack: Error
  at assertTrue (utility.js:59:23)
  at runtime.js:114:9
• test_raytrace is failing because it includes iostream from the installed C++ library.
• test_strings fails to run because it doesn't have an implementation for __01___isoc99_sscanf. This seems to be a problem with the libc headers I'm using now. I yanked them from an Ubuntu install, I think they use eglibc.

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

[kripken]

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]

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]

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]

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]

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

[snowyu]

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]

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.