[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Re: Boost-linkage
From: |
Rob Savoye |
Subject: |
Re: [Gnash-dev] Re: Boost-linkage |
Date: |
Fri, 06 Oct 2006 09:37:48 -0600 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060913) |
Markus Gothe wrote:
> Ahh, yes --disable-shared is good. Then we can see unused linkage etc by
> the binary. Only makes sense for that kind of tasks (and speeding up
You can also run "ldd" on the executable (in */.libs) to see what it
actually uses. The main advantage to using static libraries is we'd save
the libtool overhead of building both object files for each source file,
as the shared ones get built with -fPIC.
If we decided to *always* statically link the internal Gnash libraries
(which we couldn't do if the plugin still depended on them) is to drop
using libtool for all the libraries and executables, and just use "$(AR)
-rv" directly. If the plugin still used libtool, it'd be dynamically
linked.
I'm still curious why we'd want to do this. If it's a debugging
problem, I use "libtool --mode=execute gdb gnash", which sets up your
debugging environment correctly to find all the right libs.
> compilation time), so you're probably right then. Might speed up
> starting time(?), unless we run 'prelink'. However I'll fix the plugin
> to always be built as a DSO.
It could improve startup time, but as also have to load other
libraries dynamically (like GTK, or KDE) you'd loose out again. For some
systems we'd want to have a fully linked executable, but this would
likely only be possible with a SDL or FLTK using AGG configuration.
- rob -