New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xcode reports non-portable path to header #3218
Comments
I have the same problem! I am using the Firebase/remoteConfig pod which depends on this protobuf pod and the builds results in all these warnings |
So the name should be "Protobuf", can you double check the pods chains you have to see if something is using it in lowercase and that is what is causing the problem? |
Actually, looking at your error, I'm a little confused:
Notice Is there anyway you can provide an example setup that reproduces this so we can finish confirm if it is some configuration specific issue vs. a basic problem with the library? |
@sergiocampama any ideas on what could be causing this? |
I found that CocoaPods will search header in
I suspect that Xcode will check real path. When Xcode find the first letter of directory name in real path is not uppercase, it reports a non-portable warning. If the |
Ugh. That could makes this more complex, because if someone build a framework with an Xcode project, it will copy the files and the capital P would be correct. Since the name of a file can be changed with a symlink, it sorta seems like clang should be checking the name it read the file as and not the target of the link. So it likely makes sense to open up a radar against clang and the support around |
Here's a quick tests I tried to setup that doesn't seem to repro it (you'll need to do the |
We still see this warning. Can be always reproduced with gRPC's helloworld example with Xcode 9.2 and Cocoapods 1.4.0. |
I'm seeing this warning in my project as well, and am able to reproduce the issue as @muxi described. |
Seems to be related to the symbolic link from the static library public header in an upper case directory to the source in a lower case directory:
|
That's what I'm seeing as well. Can I resolve this warning by modifying my local setup, or should a change be made to the CocoaPod? If the latter, should this issue be reopened? |
So clang is following the symlink and looking at the path the link cocoapods created resolves too? And just because it happens to have the same name (but different case), clang kicks out this warning? But if the target directory had a different name, clang would probably go silent? If that's the case, it sounds more like pushing this over to clang for looking at the resolved path vs. the path the header was found at is the right "solution". |
Ah, now I better understand your earlier comments about clang, thanks. I started to put together a sample project for a radar, and noticed I can only repro the issue with:
I could not repro the issue by using @thomasvl, does this change your understanding of the problem, or should I go ahead with the radar? Two other notes:
|
I haven't gotten a chance to look at your example, but answering the other parts: I'd go ahead and file the radar, point out how the Framework/include is clearly done via the capital 'P' version, but since it points to a symlink under the hood, clang is checking the wrong path. Your change - yea, it makes sense that that "fixes" it, but just like you couldn't get the warning in other situations with different links/directory structures, I'd expect that change to result in warnings in the other cases where the change would now be wrong compared to the real paths on disk. i.e. - it works in one condition, but not the other. Stack Overflow comment - Yea, I sorta figured they added the warning to help developers with the migration from cases insensitive files systems to case sensitive ones. But they seem to be looking are a symlink resolved path instead of the path clang actually found the file via. So while trying to help with one filesystem issue, the coded another one. 😮 |
I also tried a bit to repro in a smaller example yesterday and failed. I did verify that moving
So +1 on the radar, but there is something in addition to the symbolic link to the lower-cased directory that is necessary to trigger the issue that we don't fully understand yet. |
Ok, thanks. I submitted rdar://38963247 and copied it over to Open Radar: https://openradar.appspot.com/radar?id=6091887509241856 |
Update Obj-c imports to match case of sym-linked files protocolbuffers#3218
With the Xcode 10.2 beta, this issue now shows up in dynamic framework (use_frameworks!) CocoaPods installations in addition to static library configs. |
@jhoanarango I think the problem is with the capital 'P'. I was facing the same issues. I know what I did was bad but I unlocked each file changed it to a lowercase 'p' This removed the warnings. Im not to sure but I feel while installing the pods it cant find the "Protopuf" files and when changed to lowercase it seems to work fine. I hope this helps. |
@DhruvTekchandani , thank you.. I saw that too, and Xcode even suggested to change it, but I didn't want to do that since I didn't know if it would introduce other bugs or something. On top of the file it says "DO NOT EDIT" lol so I was afraid of doing so. But I guess it has to be done. |
+1 same issue in Xcode 10.2.1, in my Swift 12.0 project. I am using "use_frameworks!" too. |
it happens to me too. Protobuf and FirebaseMessaging folder ... do you suggest not to worry and to continue ignoring the warning or someone has solved ?? thanks guys ... I'm a newbie ... anxiety |
Put |
I've got this error as well. Seems like it differs if you've got a case sensitive disk format or not. |
Renaming the folder from "/[Your Project]/Pods/Protobuf/" to "/[Your Project]/Pods/protobuf/" just made the warnings dissapear in my case |
And that doesn't disappear after you run |
Hadn't tried that but the warnings came back anyway when I tried running the app on the simulator. Added this to podfile: pod 'Protobuf', :inhibit_warnings => true Ran pod install and no warnings so far. |
Theory (not sure how to confirm this would fix it or how to go about the migration) – Change the name in the Protobuf.podspec to Since that effectively is a rename of the pod, I'm have no idea how bad/hard that would be to actually pull off given everyone reference the capitalized name. @paulb777 any ideas if this would fix it or how to do this? |
@thomasvl Maybe. I'll do some investigation later this week. |
Ciao ragazzi... Il mio maestro mi ha detto di non preoccuparsi... Non è un errore... I pod si adegueranno con il tempo x Swift5... Poi mi ha detto che x far approvare l App non sarà un problema... |
Renaming the pod and module would require migration for CocoaPods clients. A better CocoaPods solution is renaming the header directory. I sent a PR doing this at #6190. |
Can confirm renaming the Protobuf directory solved all errors for me. |
#6190 doesn't work since while it renames the directory, the directory actually comes from the input paths of the files that are generated, so the next time they regenerate (especially on a case sensitive file system), the lower case names would be recreated. |
It seems there is a solution for this. Publish a new pod and deprecate the current. |
Yes, that process can work, but if someone depends on the pod via two dependencies, they need them both to update at the same time otherwise they will get two copies of the code (thru the differing names) and that will result is duplicate copies of the code that conflict. If they directly directly depend on the pod it is pretty easy, it is when they are transitive that is quickly gets hard because they need other things to update. |
Would related: CocoaPods/CocoaPods#6683 |
@BugsBunnyBR Good idea! It seems to work in #6464 |
#6803 got opened which seems to loop back to this original problem, and it seems Anyway, for those that were on this issue, you might want to track the other one also, as this could still be a problem in some configurations. |
I use CocoaPods to add Protobuf to my project. However when I build with Xcode 8.3.2, it reports so many following warnings:
The text was updated successfully, but these errors were encountered: