Re: [Gnash-dev] Re: Boost-linkage

[Rob Savoye]

Markus Gothe wrote:

> Looking at pkgsrc, they have splitted the boost-pkg so you can choose
> just to install the headers (which is actually what I did on IRIX alas
> compilation fails due to TU-smart pointers)...

  If you don't link in the boost_thread library, you get undefines from
using the headers, so for threading I think we're stuck with this. I
just build Boost from source, and it installs in
/usr/local/include/boost-1_33_1/. Yeuch... I'm not so sure the Boost
developers and me are on the same planet when it comes to portability...

  While a lot of Boost looks really good, I'm starting to think any of
the Boost code that needs a library is going to add a huge mess of
configuration options. My current thought for the morning (here I just
got up and just made some coffee) is to not use Booth mutexes and
threads. For at least these two, we're potentially better off sticking
to just using POSIX threads and mutexes. I already have a portable
Thread class in libbase, and I'm debating adding a Mutex one, and
blowing off Boost for this as overly complex.

> strk suggested earlier today that we statically link the libgnash*
> libraries into the binaries which I agree on (and working on modifying
> the makefiles so they conform to this as we still want the plugin to be
> a DSO-binary).

  You can do this by configuring with --disable-shared. Right now the
plugin has zero dependencies on any other Gnash libraries, and the
plugin *must* be dynamically linked anyway so the browser can load it.
Why not just use the shared libraries ? For Gnash, it probably doesn't
matter either way, but I'd be curious why. Other than compiling time, I
don't really see an advantage to making the Gnash executables statically
linked.

        - rob -