[sr #111011] restore shared library support on Android

Follow-up Comment #8, sr #111011 (group libtool): Nothing personal - usefulness of "hard coded path" for Android and Windows is lie. Build tools are for general use not for personal one. I'm sure that personal environment could be setup do not require hard coded paths. ___

[sr #111011] restore shared library support on Android

Follow-up Comment #6, sr #111011 (group libtool): Last comment is misleading. Goal of build tools is to help package manager(build engineer) to prepare installation. For private environment always exist work-around. Use hardcoded paths on Windows and on Android does not make sense even in privat

[sr #111011] restore shared library support on Android

Follow-up Comment #4, sr #111011 (group libtool): Key rule: "Android and Microsoft Windows must not hard code any paths". There is no room to discuss core functionality for both OS-ses. Applications(programs) could be installed in any location(path)! __

[sr #111011] restore shared library support on Android

Follow-up Comment #2, sr#111011 (group libtool): Note subject explain all. One recent commit broke Android build. Patch just restore correct behaviour that was used before. ___ Reply to this item at:

[sr #111011] restore shared library support on Android

Additional Item Attachment, sr#111011 (group libtool): File name: restore-shared-library-support-on-Android.patch Size:1 KB AGPL NOTICE These attachments are served by Savane. You can down

[sr #111011] restore shared library support on Android

: None ___ Follow-up Comments: --- Date: Sun 28 Jan 2024 12:06:48 PM UTC By: Румен Петров Recently rules for android linked was updated irrationally. Attached patch restores previous correct(!) behaviour and u