Thanks, fixed. Regression was from 6556a69f282ec534512c3e6a119328fe98886a97, we started to use the order of inputs to handle --start-group etc., but had the order of -lX libs wrong (it has to be at the end, turns out).
- Alon On Mon, Aug 4, 2014 at 4:24 PM, Brion Vibber <[email protected]> wrote: > Here's a test case here: https://github.com/brion/test-emscripten-lib > > Though now that I look at it that might not be the same problem as Phil is > seeing; I can link the libtest.a file directly, just not via -ltest. > > Perhaps the .a is not being built correctly with emar? > > -- brion > > > On Mon, Aug 4, 2014 at 9:33 PM, Alon Zakai <[email protected]> wrote: > >> Please bisect the regression if you can. Testcase is best, but otherwise >> bisection that shows where the regression started is almost as good. >> >> - Alon >> >> >> On Mon, Aug 4, 2014 at 12:53 PM, Brion Vibber <[email protected]> wrote: >> >>> I actually noticed a regression in SDK release 1.21 with linking >>> static-only .a builds of ogg/vorbis/theora on my ogv.js project; switching >>> from .a to .so builds resolved it and was easy enough for my workflow that >>> I didn't think to report it. But if that's not an intentional change in the >>> linking support, then there might be a bug there... >>> >>> -- brion vibber (brion @ pobox.com / bvibber @ wikimedia.org) >>> >>> >>> On Mon, Aug 4, 2014 at 8:13 PM, Alon Zakai <[email protected]> wrote: >>> >>>> 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. >>>> >>> >>> -- >>> 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. >> > > -- > 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.
