Header paths broken in v141

[tleyden]

Thanks for creating this project! I just found out I was using a 2 year old GoogleWebRTC pod in my react native project, so I'm trying to switch over to the more recent code in the WebRTC-lib pod.

Unfortunately when I try to use this pod I get build errors:

❌  (../Debug-iphonesimulator/XCFrameworkIntermediates/WebRTC-lib/WebRTC.framework/Headers/RTCCodecSpecificInfo.h:13:9)

  11 | #import <Foundation/Foundation.h>
  12 |
> 13 | #import "sdk/objc/base/RTCMacros.h"
     |         ^ 'sdk/objc/base/RTCMacros.h' file not found

It seems that in the Headers it expects a different directory layout than what's actually on the filesystem, whereas in the older GoogleWebRTC it expects headers to be in the same dir.

WebRTC-lib/WebRTC.xcframework/ios-x86_64_arm64-simulator/WebRTC.framework/Headers > cat RTCCodecSpecificInfo.h
....
#import <Foundation/Foundation.h>

#import "sdk/objc/base/RTCMacros.h"

vs with the GoogleWebRTC for the same file:

> cat RTCCodecSpecificInfo.h
....
#import <Foundation/Foundation.h>

#import "RTCMacros.h"

Has anyone else run into this? Any suggested workarounds?

[tleyden]

Here's a workaround that is super clunky, but it gets past those compile errors:

cd ios/Pods/WebRTC-lib/WebRTC.xcframework/ios-x86_64_arm64-simulator/WebRTC.framework/Headers
mkdir -p sdk/objc/base/
emacs -nw make_hardlinks.sh

and add content to script:

for f in *; do
  if [ "$f" != "sdk" ]; then
    ln "$f" sdk/objc/base/"$f"
  fi
done

then:

chmod +x make_hardlinks.sh
./make_hardlinks.sh

Now it can see the headers in the expected place.

[markusboesch]

@tleyden This is a very weird regression that was introduced after the release of version M140. It is not related to this particular build process but rather the original source code. Until this is resolved you could stick with version M140 which should work just fine.

[tleyden]

Thanks @markusboesch. Do you happen to know if there’s already an upstream tracking ticket on the google libwebrtc repo? If not I can search and possibly file one.

[markusboesch]

Hi @tleyden, I did a quick check a few days ago, but couldn't find any ticket about this issue. Strange but I reckon most people don't update their WebRTC framework version with every new release. Can't explain why this wasn't discovered before since the stabilization phase of a release takes several weeks, and iOS as a platform really should be common enough these days 🤔

Thanks for your efforts, looking forward to your ticket!

[tleyden]

I checked the issue tracker and found a ticket, and cross-linked it with this issue:

https://issues.webrtc.org/issues/450130875

[markusboesch]

@tleyden Amazing, thank you for forwarding it! 👏

Apparently, this happened on the very same day. Hope they will resolve this soon. Still very surprising to me how this passed their code reviews since this particular header file was imported entirely different than any other header file 🤔

[tleyden]

I have an idea but I'll hold off on speculating 😄

[hugehoge]

Hi @tleyden @markusboesch

I've faced the same issue and reported it in the ticket:

https://issues.webrtc.org/issues/450130875

It seems we crossed paths, my apologies.

I was also confused by the lack of response, considering this should be a critical issue. I hope it gets fixed before the M142 release.

[eun-ice]

Should we change the title of this issue? Because this issue also happens to me and it's just a simple swift project. Downgrading to 140 solves the issue.

[markusboesch]

@eun-ice I agree. The issue is unrelated to React Native. Renaming it makes it easier for others to be discovered.

What do you think about this @tleyden?

[tleyden]

Yeah good point, I just updated it