If .dll linking is improper on windows then it sounds fine to remove it. I am a little concerned about reversing the order of libfile.x vs file.x, but I don't know how likely it is to break things. It seems this would make things more correct for windows, but we would be doing it on all platforms, which seems potentially wrong.
- Alon P.S. In practice .so support makes porting code easier. Yes, it might be "not really a shared library", but generally the only other option is .a files which have confusing link semantics. Because of that I've recommended people use .so's. (Of course .bc is even better, but existing projects often can emit either .a or .so.) On Wed, Jul 2, 2014 at 4:24 PM, Jukka Jylänki <[email protected]> wrote: > I think we definitely want to remove .dll from the list. On Windows, one > never links to a .dll on the command line. Instead, each dll either comes > with an associated import library (.lib) that one links to. > > Emscripten abuses the linking to a .so output, since Emscripten-generated > .so (and .dylibs) are not dynamic libraries, but instead they are either > archive files containing object files, or LLVM bitcode files. I can > understand existing configure-based builds linking to .so/.dylib suffixes > for compatibility/build system emulation purposes, but I don't think it's > particularly good form for any first-hand developers to do when developing > their build systems for new non-port projects. > > Perhaps as a middle-ground we could do the following changes for -l: > > 1) never search for .dll, since that's never even done on native Windows > either > 2) retain the .so and .dylib for compatibility > 3) always search all libfile.x before file.x > 4) add search for libfile.bc and file.bc as an Emscripten-specific static > library format. > > Currently (by default, but one can override) both CMake and Visual Studio > plugin generate files with the suffix .bc to serve as static libraries, > instead of the suffix .a. I like that in particular since it makes explicit > distinction between a native library file and a LLVM bitcode. > > Can anyone think if this scheme would pose some problems/regressions? > > -- > 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.
