[rmcore]

All,

I am trying to trace through how libs are linked in the Android build. I am using

lib/libexif as an example.

What I notice is that the file JpegIO.cpp includes libexif.h. So I assume that JpegIO.cpp is going to call functions provided by lib/libexif. JpegIO is in the xbmc/guilib directory. When I look at the Makefile.in in the xbmc/guilib directory I see

a list of SRCS
some conditionals for USE_OPENGL and USE_OPENGLES
LIB=guilib.a
two include statements
a try build target

What I don't see is where the exif lib is linked with the guilib. Can someone tell me where this linking happens? How does JpegIO.cpp call functions in the exif lib without getting "undefined reference" errors when linking?

[davilla]

you will never find a link line in the sub Makefiles... i.e. exif lib would never be linked with the guilib. There is no guilib.so

For linked libs, see the main Makefile, i.e. LIBS=

For libexif in particular, it's dyloaded, see xbmc/DllPaths_generated_android.h, DLL_PATH_LIBEXIF

[rmcore]

davilla,

That does bring up another question. In the file Makefile.in can you explain what this means:

LIBS=@LIBS@

I interpret this to mean that the make file variable LIBS is assigned the value of the auto tools variable @LIBS@. But I don't see where @LIBS@ is defined.

---

davilla,

I see a libs target in the Makefile:

libs: libhdhomerun imagelib libexif libSyncByteFuncs system/libcpluff-arm.so $(CMYTH)

Presumably this allows the libs to be built as a unique build target.

There is a LIBS variable in the Makefile. However libexif is not listed for the LIBS in the Makefile.

I have been looking through the top level Makefile.in and the top level Makefile. I am still confused about how something like the xbmc guilib links against a lib such as libexif. I can see that for the build target libxbmc.so the LIBS variable is used (also for the build target xbmc.bin) But as I mentioned libexif is not part of the LIBS. I still don't see how libexif is linked.

[rmcore]

davilla,

Can you explain dyloaded? I thought all .so files were dynamically loaded at run time.

[davilla]

LIBS=@LIBS@

configure does a symbol replacement of @LIBS@ when it creates a Makefile for Makefile.in . It's AutoTools magic and is a predefined symbols that is automatically replaced rather than one explicit by AC_SUBST(xxx).


xxx.so files can be hard linked and then they will be loaded at runtime by the loader. xxx.so files can also be dyload'ed at runtime. google 'dyload' . This means we don't have to worry about link time issues, we load and unload the lib as needed. When you hard link, you cannot control when the lib loads, nor can you unload it.

libexif is not listed in LIBS, it's dyload'ed so it appears in DLL_PATH_LIBEXIF, grep DLL_PATH_LIBEXIF and follow it.

stop thinking that xbmc guilib links to something, xbmc is the binary app, not guilib. xbmc/guilib/guilib.a is a static lib that is created from the source code in xbmc/guilib. Its a build system construct helper static lib, just to make building easy.


XBMC dyload's many libs at runtime, these libs are not linked. We have code that actually does the dynamic load and as such we don't need to hard link to them.

Note that many libs under android are built as static libs and not dynamic libs. XBMC links direct to them just like it does with guilib.a. Symbols are resolved at link time.


'libs' is just a Makefile target, it's used to group sections

libs: libhdhomerun imagelib libexif system/libcpluff-x86-osx.so $(CMYTH)

For example see below
externals: codecs libs visualizations screensavers libaddon pvraddons

[davilla]

maybe if you said something about what you want to do, I can be more helpful

[rmcore]

davilla,

I want to put some functions in a library and call them from *.cpp files in the DVDInputStreams.

I modeled my library after the libexif library. I have modified several files but I keep getting "undefined reference" when the make command tries to link libxmbc.so. The files I modified are:

Code:

#    modified:   Makefile.in
#    modified:   configure.in
#    modified:   xbmc/DllPaths_generated.h.in
#    modified:   xbmc/DllPaths_generated_android.h.in
#    modified:   xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.h
#    modified:   xbmc/cores/dvdplayer/DVDInputStreams/DVDInputStreamFile.cpp

I have also noticed that libexif-arm.so gets placed in several directories but the library I created does not.

Code:

adev@android-dev-precise64:~/xbmc-android$ find . -name *.so | grep libexif
./tools/android/packaging/xbmc/obj/local/armeabi-v7a/libexif-arm.so
./tools/android/packaging/xbmc/lib/armeabi-v7a/libexif-arm.so

[davilla]

yep, you did not add it to tools/android/packaging/Makefile

Again, stop using libexif as an example, it is dyloaded, not hard linked. If you want something hard linked, then use libtiff as an example.

[rmcore]

davilla,

"XBMC dyload's many libs at runtime, these libs are not linked."

Thanks for the background. I couldn't find where libexif is linked in the makefiles because it is not linked.

I did a google search for dyload. I didn't find much. The first result is a github repo:

https://github.com/xymostech/dyload

The second result is a link to a commit on the xbmc repo of github. Do you have any more documentation on dyload?

[rmcore]

davilla,

Is DynamicDll.h needed for the dyload functionality? I had thought that DynamicDll.h was obsolete based on this response.

http://forum.xbmc.org/showthread.php?tid...pid1576057

"The wrapper was needed to allow dll's using XBMC's virtual filesystem. This is obsolete now but the wrapper is still in place."

[davilla]

do you see DynamicDll.h used in xbmc/cores/dvdplayer/DVDCodecs/Video/AMLCodec.cpp ?

wrapping is different than dyloading.


DllLibAmCodec *m_dll;

m_dll = new DllLibAmCodec;
m_dll->Load();
am_private->m_dll = m_dll;


That just dyloaded libamplayer.so

again, see xbmc/cores/dvdplayer/DVDCodecs/Video/AMLCodec.cpp if you want to learn about dyloading.

[rmcore]

davilla,

I see the following in the file AMLCodec.cpp:

#include "DynamicDll.h"

class DllLibAmCodec : public DllDynamic, DllLibamCodecInterface

DllLibAmCodec has multiple inheritance.

It seems from the code example, that if I want to create a new library that is dyloaded it will have to inherit from DllDynamic. Is it the DllDynamic class that actually implements the dynamic loading?

[davilla]

It's certainly not DllLibamCodecInterface

[rmcore]

davilla,

Thanks for your help. I was able to create a dyloaded library.

Is the dyloaded functionality needed because of the way android handles shared libraries? Or is there another reason?

[davilla]

no, it comes from the original xbox usage where ram memory was very limited and libs were loaded and unloaded as needed. It still remains a nice way to handle external lib usage and some platforms (like older Android and iOS) have much less ram that is on desktop boxes.


android handling of shared libraries requires even more tricks that are transparent to code and are handled in the lib build and packaging steps.