We don't have any known bugs on .a linking, so if you can reduce it and file a testcase, that would be useful (we do have #2568 on .a with groups, but unless you are using groups it is probably something else).
- Alon On Sun, Aug 3, 2014 at 7:16 PM, <[email protected]> wrote: > Well, seems like emscripten isn't playing nicely with the .a archive. > > Running emcc on individual files in the library allows the functions to > make it through to the JavaScript. > > Now I have a handful of functions running in the browser, and am working > through figuring out how to use them. > > Thanks! > > > On Sunday, August 3, 2014 10:45:48 AM UTC-7, [email protected] wrote: >> >> Following up... I am able to get libsisl.a to compile as llvm bytecode. >> The output of llvm-nm is attached. >> >> I believe the issue here may be that all of the functions are getting >> optimized away, similar to https://github.com/kripken/ >> emscripten/issues/1531 >> >> But as a test, naming one of the functions explicitly in >> EXPORTED_FUNCTIONS does not seem to help: >> >> $ emcc libsisl.a -o example.js -s >> EXPORTED_FUNCTIONS="['_malloc','_main','s1240']" >> -v >> emscript: ll=>js >> emscript: scan took 0.000397920608521 seconds >> emscript: split took 0.00169897079468 seconds >> emscript: phase 1 took 0.162272930145 seconds >> emscript: phase 2 working on 1 chunks (intended chunk size: 1.00 MB, >> meta: 0.00 MB, forwarded: 0.01 MB, total: 0.23 MB) >> . >> emscript: phase 2 took 0.52574300766 seconds >> emscript: phase 2b took 7.29560852051e-05 seconds >> emscript: phase 2c took 0.00710415840149 seconds >> emscript: phase 3 took 0.162151813507 seconds >> >> example.js has the same file size, still no functions. >> >> I believe the issue is just that the library doesn't have a main function >> (it's just a library), so all the code is removed when compiling to JS. Any >> ideas for preserving *all* the functions, or any named subset? >> >> Phil >> >> >> On Saturday, August 2, 2014 6:27:08 PM UTC-7, [email protected] wrote: >>> >>> Hi There! >>> >>> Just discovered Emscripten today. Amazing! I'm a little outside my >>> comfort zone though, and having some difficulty compiling a geometry >>> library I would love to see in JavaScript. >>> >>> Here's what I'm attempting to compile: >>> >>> https://github.com/SINTEF-Geometry/SISL >>> >>> I've gone through the tutorials and have the hello-world examples >>> running fine. When I follow the "project" tutorial, I hit some issues >>> (Running Linux Mint 16 if it's important). I was hoping I might get a >>> little help debugging, as I'm good and stuck. The steps I've followed: >>> >>> 1) Clone the SISL repo >>> 2) remove #if defined(_MSC_VER) || defined(__BORLANDC__) || >>> defined(__MINGW32__) || defined(__APPLE__) and the corresponding #endif >>> from /include/sislP.h. These contstants cause an error if not defined, >>> which they aren't in my environment. >>> 3) Run emconfigure cmake:: >>> >>> phil@Phil-LinuxMint ~/PROJECTS/SCRATCH/SISL $ *emconfigure cmake* >>> -- The C compiler identification is Clang 3.2.0 >>> -- The CXX compiler identification is Clang 3.2.0 >>> -- Check for working C compiler: /usr/share/emscripten//emcc >>> -- Check for working C compiler: /usr/share/emscripten//emcc -- works >>> -- Detecting C compiler ABI info >>> -- Detecting C compiler ABI info - done >>> -- Check for working CXX compiler: /usr/share/emscripten//em++ >>> -- Check for working CXX compiler: /usr/share/emscripten//em++ -- works >>> -- Detecting CXX compiler ABI info >>> -- Detecting CXX compiler ABI info - done >>> -- Configuring done >>> -- Generating done >>> -- Build files have been written to: /home/phil/PROJECTS/SCRATCH/SISL >>> >>> 4) Running *emmake make* errors out at the end: >>> >>> [100%] Building C object CMakeFiles/sisl.dir/src/s2511.c.o >>> WARNING emcc: -I or -L of an absolute path encountered. If this is to a >>> local system header/library, it may cause problems (local system files make >>> sense for compiling natively on your system, but not necessarily to >>> JavaScript) >>> WARNING root: Applying some potentially unsafe optimizations! (Use -O2 >>> if this fails.) >>> clang: warning: argument unused during compilation: '-nostdinc++' >>> WARNING emcc: -Ox flags ignored, since not generating JavaScript >>> Linking C static library libsisl.a >>> Error running link command: No such file or directory >>> make[2]: *** [libsisl.a] Error 2 >>> make[1]: *** [CMakeFiles/sisl.dir/all] Error 2 >>> make: *** [all] Error 2 >>> >>> 4b) I can run the regular cmake routine to successfully generate >>> libsisl.a, which I believe is llvm bytecode. But then if I attempt to run >>> *emcc >>> libsisl.a -o output.js*, I get an output js file that is 195104 bytes >>> in size but does not appear to have any of the library's source. libsisl.a >>> is ~2mb. I noticed that if I run emcc on a single .c source file, I get the >>> same 195104 byte Javascript output. >>> >>> Any ideas what's going on here? The has_source_inputs error is a bit >>> beyond my understanding of the process. I'm familiar with all the front end >>> stuff, but Objective-C is as close as I get to any of the compiler code. >>> >>> If anyone is interested in any geometry, 3d printing, or UX advice, I'm >>> happy to offer a trade :) >>> >>> All help appreciated! >>> >>> Best, >>> Phil >>> >> -- > 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. > -- 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.
