Dynamic linking
Антон Иванов
Tim Mensch
Yes, but you have to do it yourself by loading each of the libraries
from Java, so that all of the prerequisites to each library are already
loaded before you load the next.
Recursive dependencies are not supported, AFAIK, however. For that you
should statically link the libraries together.
Tim
Olivier Guilyardi
I agree that static libraries are certainly the best here.
Nevertheless, I haven't used that, but I think that recursive deps are supported
too, otherwise there wouldn't be this in docs/SYSTEM-ISSUES.html:
I. Android 1.5 System Issues:
-----------------------------
[...]
Dynamic Linker limitations:
---------------------------
[...]
- A bug prevents one application shared library from depending on another
one. For example, if you build both libfoo.so and libbar.so for your
application, and list libfoo.so as a dependency for libbar.so in
bar/Android.mk (with LOCAL_SHARED_LIBRARIES := foo), then loading
libbar.so will always fail, even if you have already loaded libfoo.so
in your process.
--
Olivier
Tim Mensch
>> Recursive dependencies are not supported, AFAIK, however. For that
>> you should statically link the libraries together.
> are supported too, otherwise there wouldn't be this in
> docs/SYSTEM-ISSUES.html:
>
> I. Android 1.5 System Issues: -----------------------------
>
> [...]
>
> Dynamic Linker limitations: ---------------------------
>
> [...]
>
> - A bug prevents one application shared library from depending on
> another one. For example, if you build both libfoo.so and libbar.so
> for your application, and list libfoo.so as a dependency for
> libbar.so in bar/Android.mk (with LOCAL_SHARED_LIBRARIES := foo),
> then loading libbar.so will always fail, even if you have already
> loaded libfoo.so in your process.
I guess I read that differently. What I see there is that ALL dependencies between shared-object files are broken in 1.5, not recursive dependencies. It just talks about libfoo being a dependency for libbar, and not vice-versa. By "recursive" I mean foo depends-on bar, AND bar depends-on foo.
That's not to say that recursive dependencies are or are not supported, just that the above bug in 1.5 doesn't say anything about it one way or the other.
Tim
Olivier Guilyardi
Ah recursive, right, sorry I didn't get your point correctly.
I actually wasn't aware of recursive deps between shared libs in general.
--
Olivier
Антон Иванов
Hello
You wrote:
Yes, but you have to do it yourself by loading each of the libraries
from Java, so that all of the prerequisites to each library are already
loaded before you load the next.
should statically link the libraries together.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Tim Mensch
If A requires B, and you load B first, then A, it should work, but apparently NOT on 1.5, so be sure to require 1.6.
Tim
Olivier Guilyardi
dynamic linking?
You'd make your life a lot easier by using static linking, eg:
- dedicate an Android.mk to each secondary library, using $(BUILD_STATIC_LIBRARY)
- then in the main Android.mk, list your secondary libraries in
LOCAL_STATIC_LIBRARIES, and use $(BUILD_SHARED_LIBRARY)
This will result in a single .so.
Not only is it simpler but it will also save space when compared to multiple .so
files, without any performance loss even if the .so is big.
Olivier
On 05/15/2011 12:51 AM, Tim Mensch wrote:
> Situations where A requires B and B requires A are mutually recursive.
> AFAIK that isn't supported.
>
> If A requires B, and you load B first, then A, it should work, but
> apparently NOT on 1.5, so be sure to require 1.6.
>
> Tim
>
> On 5/13/2011 10:05 PM, Антон Иванов wrote:
>>
>> Hello
>> You wrote:
>> Yes, but you have to do it yourself by loading each of the libraries
>> from Java, so that all of the prerequisites to each library are already
>> loaded before you load the next.
>>
>> Recursive dependencies are not supported, AFAIK, however. For that you
>> should statically link the libraries together.
>>
>> I do not fully understand the second paragraph. Ie you mean that if
>> there is a dynamic library, which requires other dynamic libraries,
>> then connecting them in Java, everything will work?
>>
>> 2011/5/14 Olivier Guilyardi <li...@samalyse.com <mailto:li...@samalyse.com>>
>> <mailto:andro...@googlegroups.com>.
>> To unsubscribe from this group, send email to
>> android-ndk...@googlegroups.com
>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
Антон Иванов
I just used the library, which is distributed under LGPl, so I decided to make a dynamic library. And right now is to remake laziness.
By the way, if you use my library there are some problems in libc.so (the library uses the libc, and it gives DEBUG). I deciphered the DEBUG and received:
0000f110
pthread_detach
/ Opt / digit / android / main / cupcake / android / bionic / libc / bionic / pthread.c: 668
0000d362
__atomic_dec
/ Usr / local / google / home / digit / android / main / cupcake / android / bionic / libc / arch-arm / bionic / atomics_arm.S: 54
00008c86
?
?: 0
00011dc4
popen
/ Usr / local / google / home / digit / android / main / cupcake / android / bionic / libc / unistd / popen.c: 103
0001889a
diff
/ Opt / digit / android / main / cupcake / android / bionic / libc / stdlib / strtod.c: 866
If you ever met with such, then tell me what could be wrong?
Антон Иванов
2011/5/15, Антон Иванов <wkyb...@gmail.com>:
Olivier Guilyardi
And I am not a lawyer, but AFAIK you are confusing dynamic linking with the
relink requirement.
What the LGPL requires is that a user must be able to compile the version of
library that he/she likes, and relink this into your app.
So, for instance, even with dynamic linking, the user will not be able to relink
unless:
1. he has write access to <dataDir>/lib and can overwrite an existing lib
2. or he has access to the APK, can replace a library and repackage,
3. or your app provides a way to load user libraries with dlopen()
Unless the device is rooted, I think that 1. doesn't work.
For 2. if the user can repackage the APK, then you don't even need dynamic
linking, static linking may also work if you provide the user with the other .a
and .o objects. But dynamic linking is more simple here I think.
I personally use method 3. with a custom setting to load user libraries.
Olivier
> 2011/5/15 Olivier Guilyardi <li...@samalyse.com <mailto:li...@samalyse.com>>
> <mailto:li...@samalyse.com> <mailto:li...@samalyse.com
> >> <mailto:andro...@googlegroups.com
> <mailto:andro...@googlegroups.com>>.
> >> To unsubscribe from this group, send email to
> >> android-ndk...@googlegroups.com
> <mailto:android-ndk%2Bunsu...@googlegroups.com>
> >> <mailto:android-ndk%2Bunsu...@googlegroups.com
> <mailto:android-ndk%252Buns...@googlegroups.com>>.
Антон Иванов
will not be?
2011/5/15, Olivier Guilyardi <li...@samalyse.com>:
Olivier Guilyardi
But it has mentioned that this is a possibility. As I said, I'm doing this with
dlopen() and I've never tried to distribute .a and .o files for LGPL compliance.
My main point is that dynamic linking is neither enough nor necessary. Dynamic
and static linking are both options, but in either case it's not necessarily
sufficient to support relinking.
It's not like on desktops where dynamic linking is enough because users have
unlimited access to "Program files" and so (which is where the confusion between
dynamic linking and relinking apparently comes from).
Olivier
Антон Иванов
I understand that you are not a lawyer, just tell me your opinion. Do you think that is enough open only. a and. o, but not open codes and everything will be ok? Thanks in advance.
Olivier Guilyardi
- the APK
- the source code that you used for the library
- the .a/.o files for your own proprietary code (without source code)
And to explain to the user how to take all this, compile the library, relink and
turn it into a new APK. Here I can't really help because I have never done that
with pre-existing object files. That said, have a look at
<NDK>/docs/PREBUITS.html and PREBUILT_STATIC_LIBRARY.
But for this method I think that dynamic linking is simpler indeed. The user
only needs to compile the .so for the library, unzip the APK, replace the
existing .so, and then zip, align, and sign the APK with his own signature.
Olivier
On 05/15/2011 09:09 PM, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ wrote:
> I understand that you are not a lawyer, just tell me your opinion. Do
> you think that is enough open only. a and. o, but not open codes and
> everything will be ok? Thanks in advance.
>
> 15.05.2011 22:02 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "Olivier Guilyardi" <li...@samalyse.com
> <mailto:li...@samalyse.com>> О©╫О©╫О©╫О©╫О©╫О©╫О©╫:
>> I don't know, I'm not a lawyer.
>>
>> But it has mentioned that this is a possibility. As I said, I'm doing
> this with
>> dlopen() and I've never tried to distribute .a and .o files for LGPL
> compliance.
>>
>> My main point is that dynamic linking is neither enough nor necessary.
> Dynamic
>> and static linking are both options, but in either case it's not
> necessarily
>> sufficient to support relinking.
>>
>> It's not like on desktops where dynamic linking is enough because
> users have
>> unlimited access to "Program files" and so (which is where the
> confusion between
>> dynamic linking and relinking apparently comes from).
>>
>> Olivier
>>
>> On 05/15/2011 08:03 PM, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ wrote:
>>> Ie if I just simply open the files .o and no problems with the license
>>> will not be?
>>>
>>> 2011/5/15, Olivier Guilyardi <li...@samalyse.com
> <mailto:li...@samalyse.com>>:
> <mailto:li...@samalyse.com> <mailto:li...@samalyse.com
> <mailto:li...@samalyse.com>>>
>>>>>
>>>>> By the way, О©╫О©╫О©╫О©╫О©╫, I know it's the subject of the thread, but why do
>>>>> <mailto:li...@samalyse.com <mailto:li...@samalyse.com>>>>
>>>>> >> <mailto:android-ndk%2Bunsu...@googlegroups.com
> <mailto:android-ndk%252Buns...@googlegroups.com>
>>>>> <mailto:android-ndk%252Buns...@googlegroups.com
> <mailto:android-ndk%25252Bun...@googlegroups.com>>>.
Антон Иванов
2011/5/15, Olivier Guilyardi <li...@samalyse.com>:
> You would need to distribute :
> - the APK
> - the source code that you used for the library
> - the .a/.o files for your own proprietary code (without source code)
>
> And to explain to the user how to take all this, compile the library, relink
> and
> turn it into a new APK. Here I can't really help because I have never done
> that
> with pre-existing object files. That said, have a look at
> <NDK>/docs/PREBUITS.html and PREBUILT_STATIC_LIBRARY.
>
> But for this method I think that dynamic linking is simpler indeed. The user
> only needs to compile the .so for the library, unzip the APK, replace the
> existing .so, and then zip, align, and sign the APK with his own signature.
>
> Olivier
>
> On 05/15/2011 09:09 PM, Антон Иванов wrote:
>> I understand that you are not a lawyer, just tell me your opinion. Do
>> you think that is enough open only. a and. o, but not open codes and
>> everything will be ok? Thanks in advance.
>>
>> 15.05.2011 22:02 пользователь "Olivier Guilyardi" <li...@samalyse.com
>> <mailto:li...@samalyse.com>> написал:
>>> I don't know, I'm not a lawyer.
>>>
>>> But it has mentioned that this is a possibility. As I said, I'm doing
>> this with
>>> dlopen() and I've never tried to distribute .a and .o files for LGPL
>> compliance.
>>>
>>> My main point is that dynamic linking is neither enough nor necessary.
>> Dynamic
>>> and static linking are both options, but in either case it's not
>> necessarily
>>> sufficient to support relinking.
>>>
>>> It's not like on desktops where dynamic linking is enough because
>> users have
>>> unlimited access to "Program files" and so (which is where the
>> confusion between
>>> dynamic linking and relinking apparently comes from).
>>>
>>> Olivier
>>>
>>>>>> By the way, Антон, I know it's the subject of the thread, but why do