Oh, yes, that is probably it. emar (which calls llvm-ar) will always produce a .a, even if the suffix happens to be .bc. To generate a non-.a file you should just link the files with emcc, not with emar.
On Tue, Sep 1, 2015 at 9:40 AM, Robert Goulet <[email protected]> wrote: > Sure, where do you want me to drop it? I'd prefer a non-public place if > that's possible? > > I also saw something strange... in all my .bc files, the header starts > with !<arch>, while the .bc files in the emscripten cache folder all > starts with BC. Could it be possible that emar still produce an archive > content even thought the final output file name have .bc extension? > > I should also mention that I am using NMake JOM instead of MinGW, if that > matters? > > > On Tuesday, September 1, 2015 at 12:17:38 PM UTC-4, Alon Zakai wrote: >> >> Hmm, very strange indeed... >> >> libcxx_noexcept.a is the system c++ library, built without exceptions. It >> should definitely not have duplicate basenames or we would see it all the >> time, and the duplication is only checked within that .a, not in relation >> to others. So I can't understand how that warning could happen - I must be >> forgetting something. >> >> Any chance you can send me the bitcode file to reproduce this locally? >> >> On Tue, Sep 1, 2015 at 8:51 AM, Robert Goulet <[email protected]> >> wrote: >> >>> CMake reports this command when it links objects together to form static >>> libraries: >>> >>> emar.bat rc ..\lib\foundation.bc @CMakeFiles\foundation.dir\objects1.rsp >>> >>> Looking at the content of objects1.rsp, it only contains a list of .o >>> files, which looks fine. >>> >>> Here's the output with EMCC_DEBUG=1 when it links a static library : >>> >>> emar: >>> ['D:\\dev\\project\\lib\\emscripten-incoming-r0\\emscripten\\incoming\\\\emar', >>> 'rc', '..\\lib\\foundation.bc', '@CMakeFiles\\foundation.dir\\objects1.rsp'] >>> ==> >>> ['D:/dev/project/lib/emscripten-incoming-r0/clang/fastcomp/build_incoming_vs2013_64/Release/bin\\llvm-ar', >>> 'rc', '..\\lib\\foundation.bc', >>> '@CMakeFiles\\foundation.dir\\objects1.rsp'] >>> >>> Looking good too. Not sure what the rc argument means to emar.bat, but >>> I guess it's there for a reason? >>> >>> Then here is the output when we link the final executable (the .js >>> file) : >>> >>> WARNING root: invocation: >>> D:\dev\project\lib\emscripten-incoming-r0\emscripten\incoming\emcc -s >>> USE_PTHREADS=1 -s USE_GLFW=3 -s USE_WEBGL2=1 -DNDEBUG -O2 >>> @CMakeFiles\main_webgl.dir\objects1.rsp -o >>> D:\dev\project\source\develop\binaries\engine\webgl\dev\project_webgl_dev.js >>> @CMakeFiles\main_webgl.dir\linklibs.rsp --emscripten-cxx (in >>> D:\dev\project\source\develop\build\engine\webgl\main_webgl) >>> INFO root: (Emscripten: Running sanity checks) >>> DEBUG root: compiling to bitcode >>> DEBUG root: emcc step "parse arguments and setup" took 0.01 seconds >>> DEBUG root: using bitcode file: CMakeFiles/main_webgl.dir/main.cpp.o >>> DEBUG root: using bitcode file: ../lib/application.bc >>> DEBUG root: using bitcode file: ../lib/engine.bc >>> DEBUG root: using bitcode file: ../lib/foundation.bc >>> DEBUG root: using bitcode file: ../lib/game.bc >>> DEBUG root: using bitcode file: ../lib/physx_cct.bc >>> DEBUG root: using bitcode file: ../lib/gl_render_device.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3CHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3CommonCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3ExtensionsCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3VehicleCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysXVisualDebuggerSDKCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PxTaskCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/LowLevelCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/LowLevelClothCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/SceneQueryCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/SimulationControllerCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PvdRuntimeCHECKED.bc >>> DEBUG root: using bitcode file: >>> D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysXProfileSDKCHECKED.bc >>> DEBUG root: using bitcode file: ../lib/lua.bc >>> DEBUG root: emcc step "bitcodeize inputs" took 0.00 seconds >>> DEBUG root: emcc step "process inputs" took 0.00 seconds >>> DEBUG root: will generate JavaScript >>> DEBUG root: including libcxx_noexcept.a >>> DEBUG root: including libcxxabi.bc >>> DEBUG root: including gl.bc >>> DEBUG root: including libc-mt.bc >>> DEBUG root: including pthreads.bc >>> DEBUG root: including dlmalloc_threadsafe.bc >>> DEBUG root: emcc step "calculate system libraries" took 1.83 seconds >>> DEBUG root: linking: ['CMakeFiles/main_webgl.dir/main.cpp.o', >>> '../lib/application.bc', '../lib/engine.bc', '../lib/foundation.bc', >>> '../lib/game.bc', '../lib/physx_cct.bc', '../lib/gl_render_device.bc', >>> '--start-group', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3CHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3CommonCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3ExtensionsCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysX3VehicleCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysXVisualDebuggerSDKCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PxTaskCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/LowLevelCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/LowLevelClothCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/SceneQueryCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/SimulationControllerCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PvdRuntimeCHECKED.bc', >>> 'D:/dev/project/lib/physx-3.3.3-webgl-r1/Lib/PhysXProfileSDKCHECKED.bc', >>> '--end-group', '../lib/lua.bc', >>> 'D:/dev/project/lib/emscripten-incoming-r0/.emscripten_cache\\libcxxabi.bc', >>> 'D:/dev/project/lib/emscripten-incoming-r0/.emscripten_cache\\gl.bc', >>> 'D:/dev/project/lib/emscripten-incoming-r0/.emscripten_cache\\libc-mt.bc', >>> 'D:/dev/project/lib/emscripten-incoming-r0/.emscripten_cache\\pthreads.bc', >>> 'D:/dev/project/lib/emscripten-incoming-r0/.emscripten_cache\\dlmalloc_threadsafe.bc', >>> 'D:/dev/project/lib/emscripten-incoming-r0/.emscripten_cache\\libcxx_noexcept.a'] >>> >>> Everything seems to be properly using .bc files *except* for this one >>> entry that was wasn't generated by our own code, libcxx_noexcept.a That >>> looks very suspicious... >>> >>> Could it be possible this might be the cause why it complains about >>> duplicates for other libraries? >>> >>> In any case, why is Emscripten generating this .a file? >>> >>> Thanks! >>> >>> >>> On Monday, August 31, 2015 at 5:54:43 PM UTC-4, Alon Zakai wrote: >>>> >>>> That warning can only happen when .a files are being linked. Perhaps >>>> build with cmake's verbose mode to see all the commands it's issuing? >>>> >>>> On Mon, Aug 31, 2015 at 12:04 PM, Robert Goulet <[email protected]> >>>> wrote: >>>> >>>>> I just tried setting CMake to output .bc files instead of .a files: >>>>> >>>>> set(CMAKE_STATIC_LIBRARY_SUFFIX ".bc") >>>>> >>>>> ...and cleaned/rebuilt the entire program. Indeed now it produce .bc >>>>> files for my static libraries, but same warnings appears. >>>>> >>>>> Looking at the makefile generated by CMake, it appears to properly use >>>>> the emar.bat tool to produce the library. >>>>> >>>>> What else could I verify? >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> On Monday, August 31, 2015 at 12:56:59 PM UTC-4, Alon Zakai wrote: >>>>>> >>>>>> Yes, bc files are just a single object file. .a files are a historic >>>>>> format that contains multiple objects and has complex linking semantics - >>>>>> e.g. only basenames are stored; the order of linking matters; etc. .bc >>>>>> files don't have any of those issues. >>>>>> >>>>>> I'm not familiar with cmake, but it might automatically generate a .a >>>>>> for a static library and a .so (which is the same as .bc or .o for >>>>>> emscripten) for a dynamic library, so telling it that might work. >>>>>> >>>>>> On Mon, Aug 31, 2015 at 9:51 AM, Robert Goulet <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Yes, I understood the warning message. >>>>>>> >>>>>>> So, I could generate .bc files instead of .a files and that should >>>>>>> fix the issue? >>>>>>> >>>>>>> If that's the case, how do I tell CMake to build my libraries into >>>>>>> .bc files instead of .a files using the toolchain file provided by >>>>>>> Emscripten? >>>>>>> >>>>>>> And what is the difference between a .a and a .bc library file? >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> >>>>>>> On Monday, August 31, 2015 at 11:44:12 AM UTC-4, Alon Zakai wrote: >>>>>>>> >>>>>>>> As the message says, the issue arises when you have identical >>>>>>>> basenames in a .a file (because .a files only store a basename). >>>>>>>> Instead of >>>>>>>> archiving >>>>>>>> >>>>>>>> dir1/name.o >>>>>>>> dir2/name.o >>>>>>>> >>>>>>>> you can rename one of those "name"s. >>>>>>>> >>>>>>>> Or, avoid .a files. Linking .o files into bigger .o files (or .so, >>>>>>>> or .bc, all the same) works fine, emcc will call llvm-link for you. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 31, 2015 at 7:26 AM, Robert Goulet < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> When building a rather large project, I get this warning: >>>>>>>>> >>>>>>>>> WARNING root: loading from archive >>>>>>>>> D:\dev\project\source\develop\build\engine\webgl\lib\libfoundation.a, >>>>>>>>> which >>>>>>>>> has duplicate entries (files with identical base names). this is >>>>>>>>> dangerous >>>>>>>>> as only the last will be taken into account, and you may see >>>>>>>>> surprising >>>>>>>>> undefined symbols later. you should rename source files to avoid this >>>>>>>>> problem (or avoid .a archives, and just link bitcode together to form >>>>>>>>> libraries for later linking) >>>>>>>>> >>>>>>>>> That one seems a bit odd to me and worries me. How do we fix this >>>>>>>>> if we use CMake to build our project using the Emscripten toolchain >>>>>>>>> file >>>>>>>>> provided? Does this means we can generate other file formats that are >>>>>>>>> not >>>>>>>>> archive libraries (.a) but are used for the same purpose? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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. > -- 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.
