Mailinglist Archive: opensuse-packaging (174 mails)

[Cristian Morales Vega <cmorve69@xxxxxxxx>]

2009/3/16 Michael Matz <matz@xxxxxxx>:
> Hi,
>
> On Fri, 13 Mar 2009, Cristian Morales Vega wrote:
>
> > 2009/3/11 Cristian Morales Vega <cmorve69@xxxxxxxx>:
> > > I would still like to know from someone with more knowledge of linker
> > > internal working. But seems to not matter? In the binary linked
> > > against ffmpeg the symbols are just marked like undefined whatever
> > > they are D or B in ffmpeg?
> >
> > After reading a little, I understand thing a little better.
>
> I haven't investigated what the package you talk about actually does to
> create the fake library, but from what you say in this thread it seems
> that it constructs the fake library by taking the binary full binary, i.e.
> the ET_DYN .so file, and removing some sections.  Is that correct, or is
> it only how you try to solve the problem?

The original libffmpeg-api packages just creates a library from an
empty file doing "gcc -o empty.so --shared empty.c"... it doesn't
works. The package was never completed to a point where it would work.

The section removing idea was my attempt to make it work.

> In any case, this would be _extremely_ fragile, and generally a terrible
> idea.  The only way to sensibly generate such fake library is by parsing
> the original exported symbols from the .so file, generating a C source
> file from that info, implementing empty functions and defining data
> symbols (of the right size), of the right visibility and version info (the
> latter can be done by inline asm or by a linker version script).

Something for this summer. Too much work for me right now, I don't
even know asm or relocation types (I just looked to know what a COPY
reloc was). Still, a good way to learn all the internals.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx