I think, this can help...

Zitat

Writing a shared library

There are basically two files that have to be written for a usable library. The first is a header file, which declares all the functions exported by the library and will be included by the client in the code. The second is the definition of the functions to be compiled and placed as the shared object. For our example, the header file looks like this:

Listing 2: Libprint.h Code; Header file

/* file libprint.h - for example use! */
void printstring(char* str);

The code for the library is pretty basic and is shown in the next listing.

Listing 3: libprint.c Code

/* file libprint.c */
#include "stdio.h"
void printstring(char* str)
printf("String: %s\n", str);
}

There are two special functions, _init(void) and _fini(void), which are called automatically by the dynamic loader whenever a library is loaded. A default implementation is typically provided for these two functions, although you can bypass these and write your own. Let us add these two functions to our libprint.c code to print out diagnostic messages whenever they are called.

Listing 4: Code for _init() and _fini()

void _init()
{
printf("Inside _init()\n");
}
void _fini()
{
printf("Inside _fini()\n");
}

Now we combine this with the code in Listing 3. Pretty simple, huh? To write a custom library you just have to use the templates of libprint.c and libprint.h and then write the appropriate functions. Now let's go ahead and compile the library.

==========

Compiling a shared library

The sequence of commands to compile the library are:

$ gcc -fPIC -c libprint.c
$ ld -shared -soname libprint.so.1 -o libprint.so.1.0 -lc libprint.o

Notice the -fPIC option in the gcc command line. This is essential to produce Position-Independent Code. Translated into English, this command means to "generate code that can be loaded any where in the process space of a process". It's also very important for a shared object. By using this option, the number of relocations that have to be performed are cut down to the very minimum. On loading a shared object that is used by an executable, some space has to be allocated for it. And the text and data sections have to be allocated some locations. If they are not built in a position-independent way, then a fair amount of relocations have to be done by the program loading the shared object, thus impacting performance adversely.

Now let's analyze the options passed to ld. The -shared option indicates that the output file is supposed to be a shared library. By specifying the -soname name option, we specify what the soname will be. The -o name specifies the real name of the shared object. It is important to specify the soname and the real name because these are used during installation of the library.

Alles anzeigen

LINK

pcd
when you build enigma2-plugins in the oe after you build the enigma2. The serivicets.so will also build in enigma2-plugins. When you will bild it outside bb you must add the enigma2/include in you source tree. Thake a look to the makefile in vlcplayer/servicets

Best regards,

nobody611

please read this:

Compile outside oe

pcd
i attached the powerpc servicets.so.

it will be build in enigma2-plugins.

Zitat

when you build enigma2-plugins in the oe after you build the enigma2. The serivicets.so will also build in enigma2-plugins.

That's actually something that has to be fixed.
There is the dependency loop between enigma2 and enigma2-plugins.
enigma2 depends on enigma2-plugins, so the first time enigma2-plugins is built, it won't have the e2 includes.
The second time you build, the e2 includes have been staged, but you risk building against an old version (the new version won't be staged till after e2-plugins have been built)

solution for the dependency loop is to move PACKAGES_DYNAMIC from e2 to e2-plugins, add a dependency for e2 to e2-plugins, and remove e2's dependency for e2-plugins.

Because of the e2 dependancy, enigma2-plugins* will be fully satisfied by building e2-plugins (as indicated by PACKAGES_DYNAMIC)