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 - _______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev