Execution failed for task ':pdfrx:mergeReleaseNativeLibs'. > A failure occurred while executing com.android.build.gradle.internal.tasks.MergeNativeLibsTask$MergeNativeLibsTaskWorkAction #8
Labels
Comments
|
I've tested Could you please give me your |
espresso3389
added
question
|
I am runnning this from a Here is the |
|
I've just quickly test the building process using with the following commands: And it generates Only the issue I've found is that the example code does not have |
|
@felix-synorex FYI; 0.3.1 fixes the example's |
|
@espresso3389 Hi, I'm also facing this issue in GitHub Actions environment under Ubuntu when building the app. I'm using Flutter 3.16.5. I have attached the relevant log output below. Any ideas what the issue may be? I'm open to assist you if you have any questions. Details
|
|
@astubenbord Anyway, it's your app's issue and it may be fixed by adding |
|
Similarly to @felix-synorex. adding packagingOptions to the build.gradle did not work. Weirdly though the build seems to successfully run on my Windows machine using the same flutter version. |
|
Mmm...😑 I have no idea... |
|
I was able to fix that issue by adding in the build.gradle of pdfrx package in pub-cache. For me the location was |
espresso3389
added
question
|
Fixed the issue by upgrading to 7.4.2. |
Closed
Personally it is not working, I am still getting the same errorGraddle pdfrx -> androidAlso I'm not sure it is the right solution to make a patch on this gradle Does anyone have found an another solution to this problem ? |
|
Unfortunately no. The weird thing is, it only occurs on linux in my project. No other person on my team has this issue - they use macOS and Windows. |
Well well well... |
|
Basically, it should be in app level build.gradle. Not in pdfrx's. The error implies that you are using several plugins that contains its own libpdfium.so; one is pdfrx and other plugins. So, the resolution of conflict is an app issue. |
|
I thought the same and tried editing the project gradle many times. It didn't work, the only thing that worked for me was editing the pdfrx package gradle. |
|
I think there two possible and ultimate solutions:
The first one's drawback is that pdfrx may potentially use libpdfium.so from another source and it may break the consistency (sometimes causes runtime exception). The second one is safer but it may make the final output package (apk or such) larger. It may contain several instances of libpdfium.so inside the package. How do you guys think about these options? |
|
@HeropolisDa2ny I cannot accept your PR #197 without further discussion. It's just your configuration and not ours. |
|
Yes sure, and the PR was dysfunctioning the dl open because of the exclusion from the lib. Anyway, in the error the conflict comes from these two paths
I don't get why applying However if the second option is safer I would go to the safest one. |
|
I've searched the actual reason why Gradle causes errors but nothing explain me the actual reason. Some said it's just a bug of Gradle. But if so, why no one tried to fix the bug. @HeropolisDa2ny #133 (comment) suggests |
Maybe because the problem of the gradle is too minor so nobody is working on it (as it seems to be non systematic depending on devices). "write the same packagingOptions inside app's build.gradle" is not working.
Why couldn't we merge #204 as a temporary fix so that we don't have to apply the fix on every new release. And also it would maybe make new people using your package and do not stop using it as soon as they cannot build their app. |
No no, my question is, does
I actually didn't understand the basis of the workaround. Without fully understanding the effect, I don't want to accept such workaround. Futhermore, on my projects, I didn't face such errors. And no one actually provide me with any realistic example or such. I cannot check anything about the problem. |
This setting option is working fine with me (as I work with different phone OS) only when it is applied on the used version of the package (it is not workign when I'm using it in my app graddle): It just pick the first libpdfium.so instead of not being able to decide the one to use. It's a temporary fix so that everybody doesn't have to fix it by themself at every version. Moreover it's pretty hard to give your realistic example to you reproduce the bug since we just added the package to our pubspec but if you want we can try to setup a meeting to we look from where does the problem can potentially comes. |
|
If it's too difficult to reproduce the issue with simple example, I think it is not worth to workaround the issue on pdfrx side because only few people are suffer from the issue; they should implement the workaround on their app. But if it is very easy to reproduce, and almost everyone faces the issue, I also want to reproduce it and then consider to implement the workaround on pdfrx side. |
|
Or,.... Should I merge the PR without checking anything??? Should I? Everyone, please comment some. |
I mean if it does works fine with the fix on your app then it should normally doesn't break the versions of others and also fix the versions of the ones who get the problem so ... We can just keep it as a temporary fix - keep the issue open and as soon as gradle make their fix or we find another safer/better way then apply a new fix. But I'm not sure that making every people who encounter that bug, to temporary fix it by changing the version files of their cache, is the greatest solution even more when it's a cooperative project. |
|
I need at least one more person who pushes me to accept the PR. |
|
|
In my project it only happens to me, so I don't know if I'm eligible to decide that, because I'm the only one I know that experiences that problem. |
|
In my project it only happens in the ci android build, but windows android build was fine. The pickFirst config fixed that, but only when I add it to the build.gradle of pdfrx not if I added it to the build.gradle of the app. But I also think that it is just a symptom of a deeper problem, that we should find instead of hotfixing it. |
|
For me it's essentially the same scenario @Jonbeckas faces, it also only happened in my ci builds. Is it possible to do this with environment variables? I.e. Only include the snippet if the evn variable is set? Not sure how technically feasible this is but may be an option which doesnt break other peoples builds but also allows us to temporarily fix our builds? |
|
@astubenbord I'm not a Gradle professional, but if anyone can create a PR to conditionally enable packagingOptions, it is acceptable. |
|
I think the bug could be related to the libarary declared in the build.gradle and in the CMakeLists.txt. When i remove the jniLibs part it also works for me, but I am still investigating |
|
@Jonbeckas |
|
After several hours of investigation, I finally decided to merge PR #204 anyway. There might be several side effects but the possibilities are so small. The risk can be acceptable. If any issues found in future, I or someone will file a new issue. |
|
1.0.78 contains the fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have trouble build the apk with pdfrx install.
Below is error I got
I have try to add packagingOptions like so in app level build.gradle but not working also.
The text was updated successfully, but these errors were encountered: