Emscripten: Crash when compiling zlib on OSX

[PerilousApricot]

Hi!

Using the latest emscripten from HEAD, I get:

/usr/local/Cellar/emscripten/HEAD/libexec/emcc -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -D_FILE_OFFSET_BITS=64 -c -o example64.o test/example.c
/usr/local/Cellar/emscripten/HEAD/libexec/emcc -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/gzwrite.o gzwrite.c
/usr/local/Cellar/emscripten/HEAD/libexec/emcc -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -D_FILE_OFFSET_BITS=64 -c -o minigzip64.o test/minigzip.c
libtool -o libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o 
make: *** [libz.a] Segmentation fault: 11

When executing

emconfigure ./configure --prefix=${PREFIX}${d}                                     
emmake make $MAKE_ARGS                                    

With zlib-1.28.0. I'm trying to figure out my buildchain, so I built what I considered was one of the more simple libraries.

Thanks!

emcc -v
emcc (Emscripten gcc/clang-like replacement) 1.33.2
clang version 3.7.0 
Target: x86_64-apple-darwin14.3.0
Thread model: posix
INFO     root: (Emscripten: Running sanity checks)

[kripken]

First of all, you can use zlib from emscripten ports.

As for that error, I am not that familiar with libtool. Is it a script that calls another command? If so, need to find out what it is calling. If it is ar, then it should call emar, etc. emmake sets up env vars to do that, but if the makefile ignores them, it won't work of course.

[PerilousApricot]

Thanks for the message. I was building zlib manually to try and give myself a simple library to try and build against. The project I'm using has a few dependencies I'll need to port over, so I was needing the library part to get out of the way so I could learn the emscripten parts. (a lot easier to get zlib working than openSSL, for instance..)

[bbessemer]

I'm still having this issue with Emscripten 1.37.10 on macOS 10.12.5. Currently I've patched it by editing the Makefile generated by emconfigure ./configure, removing the line AR=libtool and changing ARFLAGS to match the usage of emar.

On GNU systems, Libtool is just a script providing syntactic sugar over ar, but on macOS, it seems to be a binary. (The fact that it's segfaulting instead of displaying a proper error message is no one's fault but Apple's.) The solution to this seems to be to create emlibtool as a script which calls emar in the same way that GNU libtool calls ar, and have emconfigure and emmake replace libtool with it.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[s0l0ist]

Issue is still present trying to compile ZLIB v1.2.11 using emsdk v1.38.30 on macOS v10.15.1 (19B88). On Ubuntu 18.04 it builds as expected.

[sbc100]

1.38.30 is very old now (about 8 months old by the looks of it). That might be because you are using homebrew?

Can you try with using the emsdk? The latest version should be 1.39.3.

[s0l0ist]

@sbc100 Thank you for opening this back up.

I'm currently using emsdk and have installed the second to last tagged release sdk-1.38.30-64bit, but I cannot use any higher versions due to several conflicts with the project I'm working on.

Most notably, newer versions detect that the library I'm trying to compile is static instead of shared issue #8598. I also haven't been able to get my project working as static. emcmake, emmake appear to work, but then em++ fails to output anything.

em++ -Wall -Os --bind -o seal.js libseal*

Anyways, in addition to the reason above I also receive countless implicit instantiation of undefined template error messages in my embind bindings. After commenting ALL (~30ish) of the offending lines, I get a single output message "no symbols" and the resultant emscripten build is practically empty.

Ultimately, I'm forced to use sdk-1.38.30-64bit.

[sbc100]

Yes, emscripten never really had shared library support, and we recently changed to no longer pretending to support them. Your best bet is to get the static build working.

Aside from that is sounds like you have other issues. I don't know how embind has changed recently. If possible could you post a failing example of some binding code? Perhaps open a seprate issues the embind thing?

[s0l0ist]

@sbc100 I've successfully resolved my build issues in my own library with emsdk install sdk-incoming-64bit, wrapping some errors related to noexcept issue #9485, and using the latest command line args -s USE_ES6_IMPORT_META=0.

In the end, to compile zlib on macOS, I needed to use emcmake cmake ., emmake make, and em++ -Wall -Os -o zlib.js libz.a ... with some extra arguments I use in my configuration and then it just works!

However, compiling zlib still has this issue if you're using emconfigure ./configure and emmake make.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.