webrtc.lib : fatal error LNK1136: invalid or corrupt file

[Ilya Malyavskiy]

Since 68th branch(master too). may be a bit earlier. But the 67th branch links well(with notions, but builds). Can anybody help me please? Wanna update to the resent version but cannot. I requires a lot of time to figure out the axact commit that causes the failure.

[Ilya Malyavskiy]

Omg, sorry. 69th fails, master too. 68th is fine but requires to specify audio decoder factory and decoder libraries sparately. 

On Sun, Aug 5, 2018, 23:45 Ilya Malyavskiy <ilya.ma...@gmail.com> wrote:

Since 68th branch(master too). may be a bit earlier. But the 67th branch links well(with notions, but builds). Can anybody help me please? Wanna update to the resent version but cannot. I requires a lot of time to figure out the axact commit that causes the failure.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e2e81003-2747-4770-af22-f4a63420a441%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yves Gerey]

Make sure you `gclient sync`, clean and build from scratch.

If you want more specific advice, please give more information (your platform, steps to reproduce, ...)   :)

Good luck!

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALaQDC6Ti-U9nmUFUW2AUJ3GrajEDjSenncZzDRppnVW4gUCAQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Warm regards,

Yves

[Ilya Malyavskiy]

I'm sure for 100% because the only thing is the same for all repos is the depot_tool other were fetched and synced from scratch. The only(!) step to do is to try commits one by one starting from 68th branch. 

Platform: Win7, Win 10, VS 2017 with the recent updates.

[Ilya Malyavskiy]

Hello everybody! By 2 days of searching I have found the commit that results the error statement: 95de63b

But as for me the changes in code code must not cause such kind of failure.

May be there are something in dependencies?

Hope on your help.

[mbon...@webrtc.org]

I have never seen this error but I think you can try to compile with clang and link with lld with:

$ gn args out/Debug

This will open an editor, you can add the following two lines to your build config:

is_clang = true

use_lld = true

[Ilya Malyavskiy]

Thanks for the response - I will try.

[Ilya Malyavskiy]

Hi there! The proposal did not help.

I have built the webrtc as the following:

C:\webrtc\v69\src>gn gen ..\..\v69_libs\x64\Debug --args="is_debug=true target_cpu=\"x64\" rtc_include_tests=false is_clang=true use_lld=true" --ide="vs2017"

The vs2017 is up to date and :

- the Visual Studio 2017 (v141) toolset is used by the project then depend on webrtc.

- the SDK version is 10.0.17134.0

So, as I understand everyting is standard. 68th brach builds links fine.

The project that links the webrtc.lib in reports:

2>Generating Code...

2>C:\webrtc\v69_libs\x64\Debug\obj\webrtc.lib : fatal error LNK1136: invalid or corrupt file

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(676,5): error MSB6006: "link.exe" exited with code 1136.

2>Done building project "libCliqueApiCore.core.vcxproj" -- FAILED.

but 69th fails.

Can someone help me? 

 

On Tuesday, August 7, 2018 at 2:37:19 PM UTC+7, mbon...@webrtc.org wrote:

[Yves Gerey]

Which size is your C:\webrtc\v69_libs\x64\Debug\obj\webrtc.lib ?

Some situation which could explain the issue:

 * dependencies not properly set + parallel build -> trying to link against webrtc.lib before this one is done (thus, file seen as truncated).

What if you try to build webrtc target alone, and then the target you need?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3eef0690-254b-4141-a376-f837ac543e9e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Warm regards,

Yves

[Ilya Malyavskiy]

Hey Yves. 

 The webrtc.lib is of 39'846'362 bytes. DId not get your question - What if..?

I am just making steps from this page:

- clone depot tools

- set depot tools folder to path env. var. as the very first entry
- gclient to bootstrap

- make a folder(v69) in my case

- fetch --nohooks webrtc(creates a git webrtc repo)

- then "git checkout -b v69 branch-heads/69"

- gclient sync(from within the v69 folder ot even src)

- gn gen <path> --args="is_debug=true target_cpu=\"x64\" rtc_include_test=false" --ide="vs2017"

- ninja -C <path>

HERE I get a built webrtc

.

Then I just building my project that uses the webrtc static libraries.

Here it is required to mention that binaries generated by ninja build - examples, tests are build and linked successfully. Here I able to make a supposition that some settings that influe linkers compatibility were changed. Just note that I use stock windows comiler and linker. Previosely static libraries were compatible but starting from the commit I mentioned above - they are not.

[Ilya Malyavskiy]

Hey Yves. Once again...

>>> Some situation which could explain the issue:

>>>  * dependencies not properly set + parallel build -> trying to link against webrtc.lib before this one is done (thus, file seen as truncated).

This variant is excluded.

Because first: take the steps I metioned but checkout the branch 68

then generate and build it... and your app will link.

Then fetch the webrtc to another folder, check the 69th branch sync gen and build. And the webrtc.lib will not link. Just check. Tomorrow and what is more real I'll put a sample that shows the issue. I made it but it is at my work place.

[Ilya Malyavskiy]

Moreover I've built a;; the stuff on four different machines: first - is the Win10(desktop), second Win7(laptop), third - Win server(dont actually remembre the version but this is the win server that amazon uses at the moment) at amazon cloud. All builds are with the same result.

On Saturday, August 11, 2018 at 9:55:26 PM UTC+7, Yves Gerey wrote:

[Yves Gerey]

Thanks, your detailed description makes things a lot clearer.

You should use a consistent toolchain, since clang/msvc compatibility isn't complete [1].

That means either:

 * Make sure cl.exe is used to build webrtc. From the doc, "GN supports a hybrid approach of using Ninja for building, but Visual Studio/Xcode for editing and driving compilation."

 * Use clang for your main dev.

Or you can try to pass the flags described in [1] when building webrtc with clang.

[1] (https://clang.llvm.org/docs/MSVCCompatibility.html).

[Ilya Malyavskiy]

Yves, thanks a lot. Will try you proposal in the monday.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAKdn5-CwV_%2BCo1Zxke2-nAPAX7h30Hoju-FD-SLTRGtiJoEmfw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Per Aspera Ad Astra

[Jonathan A.]

If you are using MSVC to link your final project, you need to make sure you aren't using the included clang compiler, as they aren't compatible. I just passed in "is_clang=false" and

my app, compiled with MSVC, worked fine (well, I also had to tell it to use OpenSSL, as we linked against that too):

D:\iocommain\External\webrtc\webrtc-checkout\src>gn gen out/x86/release --args="is_debug=false target_winuwp_version=\"8.1\" target_cpu=\"x86\" target_winuwp_family=\"desktop\" use_rtti=true is_clang=false rtc_build_ssl=false rtc_ssl_root=\"d:/iocommain/External/openssl/insors/include\""

[Ilya Malyavskiy]

Hello Jonathan. Thank you very much your advice works for me. Where did you get all these magic keys?

[Alexandre GOUAILLARD]

https://www.chromium.org/developers/gn-build-configuration

"""

You can get a list of all available build arguments for a given build directory, with documentation, by typing

$ gn args out/mybuild --list

"""

gn args ./ --list > args_list.txt

see result attached, for mac, on a default configuration (no args passed on to 'gn gen').

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/edf809ff-07ff-4a0b-9025-d2f989ce2a02%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

President - CoSMo Software Consulting, Singapore

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Ilya Malyavskiy]

Many thanks, Alexandre!

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/edf809ff-07ff-4a0b-9025-d2f989ce2a02%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ashik Salim]

When building webrtc m69 branch (coming from m68 branch) the produced webrtc.lib file is very small now. Earlier it was ~400 mb, now it's ~35 mb. Is this an expected behavior with lld? Also I can no longer use the produced lib files in a visual studio project. Is there no way link.exe can read lib files produced by lld? I'm worried because going forward will the msvc compiler and linker be supported?

[Ilya Malyavskiy]

Hello Ashik. Please read the entire thread, it contains all the answers. Briefly: compile webrtc without clang(add is_clang=false to --args) this will also allow to see all the internals by ms debugger and looks for other static libraries for symbols absent from webrtc.lib. In my case I added the following(except webrtc.lib): 

• obj\api\audio_codecs\builtin_audio_decoder_factory.lib
  
• obj\api\audio_codecs\opus\audio_decoder_opus.lib
  
• obj\api\audio_codecs\L16\audio_decoder_L16.lib
  
• obj\api\audio_codecs\isac\audio_decoder_isac_float\audio_decoder_isac_float.obj
  
• obj\api\audio_codecs\g722\audio_decoder_g722.lib
  
• obj\api\audio_codecs\ilbc\audio_decoder_ilbc.lib
  
• obj\api\audio_codecs\g711\audio_decoder_g711.lib
  

Cheers!

[phog...@webrtc.org]

Hi!

As you have noticed, you now need to add certain codec libraries by yourself and they're not included in libwebrtc.a. This is intentional: the idea is that you only pay for the binary size you actually need.

However, I wonder if we should just add those things to the target that builds libwebrtc.a. Desktop platforms mostly don't care about binary size, but mobile targets do, so sdk/ should not ship with any codecs. I could add Ilya's list of targets to libwebrtc.a though to make it less confusing. You can all do this today by creating your own GN targets that depend on the things your particular application needs, but I suspect most of you don't know GN and try to stay away as much as possible :)

/ P

[phog...@webrtc.org]

Hi again!

Never mind, this was done in https://webrtc-review.googlesource.com/c/src/+/89062, so libwebrtc.a now pulls in all the codecs.

/ P

[Francesco Pretto]

Hello Yves,

On Saturday, August 11, 2018 at 7:37:33 PM UTC+2, Yves Gerey wrote:

Thanks, your detailed description makes things a lot clearer.

You should use a consistent toolchain, since clang/msvc compatibility isn't complete [1].

Is this a definitive statement from google that webrtc clang compilation is no more supported for building static libraries to be used in MSVC?

Because clang compiled M68 libs were perfectly fine when used with MSVC and compilation of M72 with is_clang=false is problematic because of assertion in protoc.exe[1].

[1] https://github.com/protocolbuffers/protobuf/issues/4874

[Christoph Kutza]

I ran into the same problem as you. The release build seems to work at least. 

[Francesco Pretto]

Hi Christoph,

On Friday, February 8, 2019 at 4:50:58 PM UTC+1, Christoph Kutza wrote:

I ran into the same problem as you. The release build seems to work at least. 

 The problem can be fixed also for Debug build. In general, if anyone encountered the assertion in protoc.exe "CHECK failed: file != NULL" with M72, it's enough to merge the fix third-party repository. From the webrtc source root:

    cd third-party

    git fetch

    git cherry-pick 39767fde81a4afab6484bca002aca9e8ba1ad44c

Which is this commit[1], "Fixed Protobuf once only singleton initialation".

In general, I would like to understand why clang is not producing msvc compatible libs anymore, which it was the case before M69.

[1] https://chromium.googlesource.com/chromium/src/third_party/+/39767fde81a4afab6484bca002aca9e8ba1ad44c

[Dmitriy Borovikov]

Hi Francesco,

I got:

L:\webrtc722\src\third_party>git cherry-pick 39767fde81a4afab6484bca002aca9e8ba1ad44c

error: your local changes would be overwritten by cherry-pick.

hint: commit your changes or stash them to proceed.

fatal: cherry-pick failed

Any ideas?

[Francesco Pretto]

Hi Dmitriy,

On Thu, 28 Feb 2019 at 19:26, Dmitriy Borovikov
<dima.bo...@gmail.com> wrote:
> L:\webrtc722\src\third_party>git cherry-pick 39767fde81a4afab6484bca002aca9e8ba1ad44c
> error: your local changes would be overwritten by cherry-pick.
> hint: commit your changes or stash them to proceed.
> fatal: cherry-pick failed
>
>

The message probably describes your situation very accurately: your
files have local modifications and then you must checking out them to
an unmodified state. Generic git knowledge helps a lot here. In my
experience, it happens frequently when playing with gclient. gclient
sync ("gclient help sync" for help) may have switches that help here,
but I don't know for sure, really.