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.

Reply via email to