library build failing with llvm

[Brian Craft]

After switching to the llvm backend, I'm seeing a problem with a library built with libtool. These warnings are generated:

libtool: link:  /home/ubuntu/emsdk/upstream/emscripten/emcc -shared   .libs/check.o .libs/check_error.o .libs/check_list.o .libs/check_log.o .libs/check_msg.o .libs/check_pack.o .libs/check_print.o .libs/check_run.o .libs/check_str.o    .libs/libcheck.lax/libcompat.a/fpclassify.o .libs/libcheck.lax/libcompat.a/libcompat.o .libs/libcheck.lax/libcompat.a/timer_create.o .libs/libcheck.lax/libcompat.a/timer_delete.o .libs/libcheck.lax/libcompat.a/timer_settime.o   -lm -lc  -O2   -Wl,-soname -Wl,libcheck.so.0 -Wl,-version-script -Wl,.libs/libcheck.ver -o .libs/libcheck.so.0.0.0

shared:WARNING: Assuming object file output in the absence of `-c`, based on output filename. Please add with `-c` or `-r` to avoid this warning

shared:WARNING: ignoring unsupported linker flag: `-soname`

shared:WARNING: ignoring unsupported linker flag: `libcheck.so.0`

shared:WARNING: ignoring unsupported linker flag: `-version-script`

shared:WARNING: ignoring unsupported linker flag: `.libs/libcheck.ver`

And the generated library has symbols defined from the standard libraries. E.g.

~/emsdk/upstream/bin/llvm-nm .libs/libcheck.so | grep unlink

0000840f T unlink

where with the old backend these would be U. This causes link errors due to duplicate symbols when later linking against the library.

Looks like the linker cli is incompatible with the old backend. Is there a work-around?

[Sam Clegg]

I'd suggest disabled shared libraries if you can.  emscripten doesn't support shared libraries built in this way but it kind of fakes them by building big objects files that then get statically linked.

The warnings are expected.. we really don't support those linker flags.

The fact that you have stdlib symbols in your objectis probably because of the `-lc -lm` on the command line there.  To make that would we would have to improve our "fake shared library" building support such that is somehow knows about libc and libm and that it should not link them into such libraries.   On a system that actually supports shared libraries libc and libc would exists in libc.so and libm.so format which the linker would know not to include in the shared library itself.  emscripten only has libc.a and libm.a which the linker *will* include in your shared library.  (I believe if you link a shared library on linux with libc.a explicitly you get the same behaviour).  

In summary, can you avoid shared libraries altother?   If not, please open a bug about the behaviour of `-lc` when combined with `-shared` and we can see if we can find a work around.

--
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 emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/a5787204-c708-4638-b378-4802e6704201%40googlegroups.com.