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.
