{ "id": "171738", "key": "TIMOB-26092", "fields": { "issuetype": { "id": "7", "description": "gh.issue.story.desc", "name": "Story", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [], "resolution": { "id": "2", "description": "The problem described is an issue which will never be fixed.", "name": "Won't Fix" }, "resolutiondate": "2018-08-17T21:19:57.000+0000", "created": "2018-06-05T09:36:05.000+0000", "priority": { "name": "None", "id": "6" }, "labels": [ "android", "libc++shared.so", "module" ], "versions": [], "issuelinks": [], "assignee": null, "updated": "2018-08-17T21:19:57.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "10202", "name": "Android", "description": "Android Platform" } ], "description": "When building a Mobile app, Titanium is injecting/copying its own libc++_shared.so (e.g Android NDK r11) file. \r\nThe file that is copied during the build phase is located within the Titanium SDK: sdk/android/native/libs/*/libc++_shared.so. \r\nBut when we provide our own libc++_shared.so file within Ti Module, it gets overridden. \r\n\r\nThis step within the build phase makes it impossible to use a custom libc++_shared.so file\r\ne.g. provided by a third party. Because in some cases, a library that a third party vendor provides relies on another libc++_shared.so file (thus NDK version) that might not be compatible with the built-in one provided by Titanium. \r\n\r\nIs there an approach or way to cope with this behaviour? I know that you shouldn't and can't mix libc++_shared.so files \r\nand this libc++_shared.so file is also crucial for Titanium features to work, but there should be a way to cope with this. \r\n", "attachment": [], "flagged": false, "summary": "Android: Way to use own custom libc++_shared.so file", "creator": { "name": "sliang", "key": "sliang", "displayName": "Shuo Liang", "active": true, "timeZone": "Asia/Harbin" }, "subtasks": [], "reporter": { "name": "sliang", "key": "sliang", "displayName": "Shuo Liang", "active": true, "timeZone": "Asia/Harbin" }, "environment": null, "comment": { "comments": [ { "id": "438308", "author": { "name": "jquick", "key": "jquick", "displayName": "Joshua Quick", "active": true, "timeZone": "America/Los_Angeles" }, "body": "This is working as intended.\r\n\r\nIf we were to allow the app developer to replace the standard C++ library Titanium's .so files link to, then you run the risk of running into a ABI compatibility issue with Titanium's prebuilt .so libraries. It would be the reverse issue that you brought up.\r\n\r\nWhat you're running into reminds me of Windows DLL hell. It's the same type of issue. Although Microsoft solved it by adding the C++ runtime version to the DLL name for libraries to link to (ex: \"msvcr130.dll\", \"msvcr140.dll\", etc.). Unfortunately, Google's Android NDK has not done the same.\r\n\r\nAre you building the .so libraries yourself? If so, then I recommend that you build with Android NDK r16c and LLVM. This will use the same \"libc++_shared.so\" that Titanium uses.", "updateAuthor": { "name": "jquick", "key": "jquick", "displayName": "Joshua Quick", "active": true, "timeZone": "America/Los_Angeles" }, "created": "2018-06-11T19:38:18.000+0000", "updated": "2018-06-11T19:38:18.000+0000" }, { "id": "438317", "author": { "name": "sliang", "key": "sliang", "displayName": "Shuo Liang", "active": true, "timeZone": "Asia/Harbin" }, "body": "Got it", "updateAuthor": { "name": "sliang", "key": "sliang", "displayName": "Shuo Liang", "active": true, "timeZone": "Asia/Harbin" }, "created": "2018-06-12T01:43:11.000+0000", "updated": "2018-06-12T01:43:11.000+0000" } ], "maxResults": 5, "total": 5, "startAt": 0 } } }