Yeah.. what happens currently in several "emconfigure ./configure"-based builds is that emscripten generates static libraries with a suffix .so or .dylib, which is because we are emulating the original build script and don't really have a concept of dynamic libraries. This is nice for compatibility, but it's a bit dirty since we have static libraries with dynamic library suffixes.
Also, looking at the manual for ld: http://unixhelp.ed.ac.uk/CGI/man-cgi?ld, in native world, specifying -lfile will look for libfile.so (libfile.dylib on OSX) libfile.a in that order (dynamic lib suffix first, then static lib suffix), and not look for anything else. I _think_, but not 100% sure, that MinGW on Windows will look for the files libfile.lib file.lib libfile.a file.a to be MS-compatible, but I am not sure in which order the files are searched for. I think the only real concern we are talking about here is when someone has both native and Emscripten static and/or dynamic libraries live in the same output directory, like Mark's case in the original post of this thread. In that light, using instead the search order libfile.bc (most definitely always Emscripten, never native) file.bc (same, for MS-compatibility) libfile.a (could be native or Emscripten) file.a (for MS-compatibility) might be slightly better than what I proposed above. 2014-07-02 16:52 GMT+03:00 Bruce Mitchener <[email protected]>: > On Wed, Jul 2, 2014 at 7:29 PM, Jukka Jylänki <[email protected]> wrote: > >> I can reproduce this locally. Looking at the code in file emcc, if you >> specify -lfile, it will try to find the library file in question in the >> following order: >> >> file.a >> file.dylib >> file.so >> file.dll >> libfile.a >> libfile.dylib >> libfile.so >> libfile.dll >> >> This causes it to catch SDL2.dll before it find libsdl2.a. The reason why >> dll files are looked for comes from an ancient commit: >> https://github.com/kripken/emscripten/commit/49c3db581aaf5122a10e500839989330b4f7e45f >> . The commit does not list a reason, but given the timeframe and that it's >> by Ehsan, I assume it would have to do something with emulating Ogre3D >> build system for Emscripten, he worked on that a long time ago. >> >> I think we should revise the libs search code for -lfile to look only for >> files >> >> libfile.bc >> libfile.a >> file.bc >> file.a >> >> in that exact order. I think we should deprecate the support for linking >> in files with other suffixes, and instruct people to use proper file >> suffixes for their generated static libraries. The fact that we try to link >> in .so and .dylib is lazy form (and .dll is most likely accidental and was >> added just for "completeness" at the time), and we should avoid that. I >> would be happy to see us grow a more rigorous convention here. What do you >> think Alon? >> > > I'm obviously not Alon, but this sounds like a good improvement to me. > Predictable and sensible behavior is a plus. Trying to emulate too many > other things just leads to confusion and poor error handling. > > - Bruce > > -- > 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.
