Yes, this is how .a linking works, it's pretty confusing actually. It selects .o files out of the the .a based on what is used. So the order definitely can matter. To make it not matter, there are the --start-group etc. flags, which keep looping until everything is resolved.
.a files can make linking faster since they avoid .o files in a quick way. But it's usually fine to avoid .a files and just use .bc/.o files that just contain plain bitcode. On Wed, Feb 17, 2016 at 4:30 PM, arnab choudhury <[email protected]> wrote: > Hey guys > > I just ran into an issue where I was seeing unresolved externals when > using Emscripten to transpile my test c++ file to JS. After digging for a > while, I figured out that the order of includes of the .a files is > important. For example, if you have 2 static libraries foo.a and bar.a, and > bar.a has a dependency on foo.a, you must necessarily specify bar.a before > foo.a when passing in command line arguments to emcc. > > In the example above, > emcc foo.a bar.a test.o -o test.js will produce unresolved externals while > emcc bar.a foo.a test.o -o test.js will not. > > Is this a known issue? I can provide more specifics if needed. > > Thanks! > -Arnab > > -- > 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.
