Re: [Ekiga-devel-list] ekiga-snapshot Debian package

[Matthias Schneider <matthias schneider TU-Ilmenau DE>]

Ciao Luca, ciao Kilian,

see my comment inline...

[deleted]
> > >> I didn't look into the code (most of which I cannot understand),
> > >> but I'm a bit surprised: shouldn't x264 acts the same as
> > >> libavcodec?
> > [...]
> > > That's something with the way the linking is done right now. If the
> > > plugin does depend on it (instead of fully dynamically load it when
> > > provided and needed), it'll show up in the Depends.
> >
> > I guessed that and that's way I specifically asked why libx264 isn't
> > fully dynamically loaded (as libavcodec).
>
> Maybe Matthias can provide a "fix" to this. Then the Depends will also
> move to Suggests.

Please let me elaborate why we have to go through all this hassles: OPAL is MPL,
libavcodec is
LGPL and x264 is GPL. It is legal to dynamically load a LGPL library in from an
MPL'ed program at
runtime, so this is the way we do it with libavcodec. MPL and GPL however are
completely
incompatible, they may not be linked to each other in any way. So we apply the
following
workaround: The H264 plugin forks and executes a separate process, which is
under the GPL. This
process then contacts the MPL'ed plugin via two pipes, whose names were passed
as arguments to the
executable. Right now the GPL process is dynamically linked to libx264. In order
to make the
plugin dependable on the existence of libx264 on the system (activate h264 if
libavcodec and
libx264 are found, deactivate if not) I can see 2 possibilities:

a) continue with the dyn. linked x264 -> execl will fail and the forked process
will be terminated
b) dynamically load x264 from the GPL process and tell the plugin via the pipes
whether the
loading was successfull or not (which can then activate or deactivate itself)

a) has the problem that as soon as the execl is executed, and the dynamically
linked lib is not
found, an error message is displayed and the entire process is terminated. The
plugin however is
waiting for the GPL process to connect to its pipes and thus blocked. Ihave been
think to address
this problem with unix signals, but the error message is still written to stdout
and could produce
bug reports of unknowing users

b) This is the more complicated approach, however we can properly signal the
plugin that the
loading has failed via the pipes and gracefully close the GPL process. Also if
tracelevel is 0, no
message will be produced.

RIght now I am investigating b) - however most of the loader code has to be
rewritten since the
libavcodec loader it is under the MPL...

[deleted]

Another thing I really would like to have some advice is

how to get the library name of libavcodec ???

I know it should be libavcodec.so, but on some distros e.g. its libavcodec.so.51
or
libavcodec.so.1d. However I have no idea how to figure that out. SOme people
have suggested
pkg-config, but that only returns -lx264 and the include paths. Any hints on
that would be very
appreciated...

Matthias

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.