Indeed, the problem goes away now. Thanks!
On Tuesday, September 1, 2015 at 1:06:28 PM UTC-4, Robert Goulet wrote:
>
> Ah! Ok then it's a bug in the Emscripten CMake toolchain file. In that
> file you specify this:
>
> if ("${CMAKE_AR}" STREQUAL "")
> set(CMAKE_AR "${EMSCRIPTEN_ROOT_PATH}/emar${EMCC_SUFFIX}" CACHE FILEPATH
> "Emscripten ar")
> endif()
>
> Which defines the archiver executable file to be emar instead of emcc.
>
> Then, it sets the "create static library" CMake command to be:
>
> set(CMAKE_C_CREATE_STATIC_LIBRARY "<CMAKE_AR> rc <TARGET> <LINK_FLAGS>
> <OBJECTS>")
> set(CMAKE_CXX_CREATE_STATIC_LIBRARY "<CMAKE_AR> rc <TARGET> <LINK_FLAGS>
> <OBJECTS>")
>
> To work-around this, I tested replacing emar with emcc, and replaced the
> rc argument with -o, and now it produces bitcode as expected!
>
> Now I'm going to test if this fixes my linking issue.
>
> On Tuesday, September 1, 2015 at 12:47:54 PM UTC-4, Alon Zakai wrote:
>>
>> 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.
