Additional Library Directories on Linker property page is a trap

[juj]

Additional Library Directories on Linker property page is a trap

[juj]

Yeah, I agree there is a problem here... I'll do some testing on this. I definitely don't want to require users to start naming their libraries in the format "libStaticLib.a/bc/lib".

[MarkCallow]

Any thoughts on how to fix this?

I just found an issue with emcc when using -l that is going to have to be fixed for any solution to this problem to work. It expands libraries, e.g. -lfoo only to libfoo.a; however when the found libfoo.a is passed to a later stage of the linker, it complains .a is an unknown suffix. If you change the name to libfoo.bc then the library is not found. See Emscripten issue 2471.

[juj]

For (Windows) Emscripten development, my recommendation is that people should always use the suffix .o for object files, .bc for static libraries, and we should make -lfile directive look for both libfile.bc and file.bc (in that order). I think that would resolve the issue here.

I commented on the mailing list on this. Let's see what others think.

[MarkCallow]

Once Emscripten issue 2471 is fixed, vs-tool will need to add the -l prefixes when it adds the names appearing in the AdditionalDependencies list to the link command.

[juj]

Yeah.. The newly released Emsdk 1.21.0 release http://tiny.cc/2npmix still has this issue, but let's hope we'll be able to fix it by the next release.

[MarkCallow]

Just tried 1.22.0. emlink/emcc no longer matches x.dll but that is the only thing fixed. In order to avoid having to change the names of "Additional Dependencies" when generating an Emscripten config from a Win32 or x64 config, -lx.lib or -llibx.lib need to work. The former case should match libx.lib or x.lib, the latter libx.lib. This is also needed for my case, generating project files with GYP, because GYP does not support per configuration library names.

vs-tool still needs to prefix the library names with -l when passing them to emlink/emcc to make it search

Please can this be fixed in the next release?

[MarkCallow]

I started to look into fixing this but can't find any documentation about VS platforms. If you can give me a clue where to start, e.g. where/how is AdditionalDependencies added to the link command line, I can take a stab at it.

What I plan to do, if I can figure out how, is to prefix each item in AdditionalDependencies with -l and remove its filename extension, if any.

[juj]

I believe that is done in the DLL that is being reused from https://code.google.com/p/vs-android/, try peeking into the sources of that project.

[MarkCallow]

I have investigated this some more. If you add the attribute 'Switch="l"' (small L) to the AdditionalDependencies StringListProperty in emcc_link.xml, then the libraries will be prefixed with "-l". emlink will then search for libraries along the search path given by AdditionalLibraryDirectories.

There is still the issue with library naming. There is currently no name that will work for both the MSVS linker and emlink. For the MSVS linker, libraries have to be foo.lib for it to search LIBPATH: directories. When emlink sees -lfoo.lib it returns cannot find library "foo.lib". I presume it fails because it is searching for foo.lib.{bc,a,lib}. There is no obvious way to remove the .lib when passing the names to emlink either with StringListProperty attributes or in the dll source.

Can we change emlink to ignore an existing extension or else not tack another extension on the end? The former may be preferable because library files can then use the Emscripten naming conventions. Such behavior should probably be behind an option flag.

[juj]

So if user passes -lfoo.lib, then only the file foo.lib would be searched, instead of (or perhaps in addition to(?)) the current foo.lib.{bc,a,lib}? That sounds like a good feature, I think we should do that. Can you ask what Alon's opinion of that is in an issue to Emscripten itself?

[MarkCallow]

I opened emscripten-core/emscripten#2986 for Alon.

I verified that emlink currently searches for foo.lib.bc and foo.lib.a in this case. I didn't try foo.lib.lib.