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]
> <javascript:>> 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] <javascript:>.
>> 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.
