Peter, like I said, OPAL in 3.0.0 did not find your speexdsp because its detection was broken. Thus you compiled without speexdsp in 3.0.0, which you can still enforce via --enable-localspeexdsp.
If you compile library x with -ly, and then link application z against x, you will still have to have access to x and y, linking z with -lx -ly. Thats also what pkg-config is used for. Matthias ----- Ursprüngliche Mail ---- > Von: Peter Robinson <[EMAIL PROTECTED]> > An: Matthias Schneider <[EMAIL PROTECTED]> > CC: Ekiga development mailing list <ekiga-devel-list@gnome.org> > Gesendet: Dienstag, den 21. Oktober 2008, 12:36:51 Uhr > Betreff: Re: [Ekiga-devel-list] ANNOUNCE - Ekiga 3.0.1 available > > On Tue, Oct 21, 2008 at 11:26 AM, Matthias Schneider > wrote: > > Peter, > > it looks strange to me that at opal compilation time you have speexdsp > > on your system and at ekiga compile time you dont. > > The Fedora build system builds every package in a separate chroot for > every package, every build requirement needs to be explicitly included > for every separate package. So for building the ptlib/opal/ekiga > package set there's 3 separate build roots and they are built in a > chain. So I don't know enough about the intrinsics of linking but > ekiga v3.0.0 run and worked fine without explicit linking of speex > (and given that it definitely wasn't in the build env as it wasn't in > the build spec file) and v 3.0.1 doesn't I asked a question as to why > it was needed. I know Fedora is getting very tight on the way things > are linked in through different dependencies and hence why I noticed > the issue and asked the question as to what had changed. > > Peter > > Actually the behaviour > > seems normal to me: > > > > - We build a OPAL shared library that requires speexdsp. > > - When we link this library, it is checked that speexdsp symbols are > > working; > > however the speexdsp symbols will NOT be included in the OPAL shared lib > > - OPAL adds speexdsp to its PKG-requires section to tell apps linking to it > that > > it accesses symbols from speexdsp > > - when ekiga links to opal, it also has to link to speexdsp in order to > resolve all symbols > > ( you would get unresolved symbols errors if not) > > - ekiga gets this information from pkg-config > > > > Matthias > > > > > > > > > > ----- Ursprüngliche Mail ---- > >> Von: Peter Robinson > >> An: Matthias Schneider > >> CC: Ekiga development mailing list > >> Gesendet: Dienstag, den 21. Oktober 2008, 11:00:21 Uhr > >> Betreff: Re: [Ekiga-devel-list] ANNOUNCE - Ekiga 3.0.1 available > >> > >> > Hi Peter, > >> > actually the dependency to speexdsp was not added, but the detection > >> > of a system speexdsp was fixed. We have two places where we use speex: > >> > > >> > speex at the speex codec plugin > >> > speexdsp for echo cancelling in opal > >> > > >> > For speex in the plugin nothing has changed. For the echo cancelling, > >> > since the detection was not working in 3.0.0, OPAL always fell back to > >> > the internal speexdsp code, which is actually quite old and caused > >> > problems > >> > on some systems (e.g. windows). You can force the old behaviour (using > >> > the internal speexdsp) by > >> > > >> > --enable-localspeexdsp > >> > > >> > in the OPAL configure line. > >> > >> I understand the detection of the speex was broken in opal. But it > >> wasn't the compilation of opal that was causing the problems it was > >> the actual compilation of ekiga. As ekiga uses opal my understanding > >> is that it shouldn't need speex directly and hence any linking to the > >> speex libraries should be done by opal and not ekiga, and in turn > >> ekiga then links to opal. > >> > >> Peter > > > > > > > > > > _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list