I've not seen many Gtk / gtkmm projects do statically linked builds, so I'm not very familiar with the procedures. I just remembered one such project that offers statically linked binaries, however: gplanarity (http://web.mit.edu/xiphmont/Public/gPlanarity.html). You could check that out to see how they do it. It's a Gtk program, not a gtkmm one, but it might help anyway.
Sorry I can't be more helpful Jonathon On 1/4/06, Bob Caryl <[EMAIL PROTECTED]> wrote: > Hey guys, > > Well, I managed to dig around and get rid of all the unresolved symbol > problems reported during link. It's amazing how much larger the > resulting executable image is; in this case, it's sixteen times larger > (and that is with all the debug stuff stripped out). I do get several > warnings that tell me that my glibc shared libs must match (between what > exists on the machine running the app and the glibc library that existed > on the machine upon which the compile and link operation occurred.) > According to what I find on google, this is not a problem unless, of > course, I am trying to run on an older machine with and older version of > glibc. > > However, any celebration on my part is premature, since the application > crashes with a seg-fault on startup that I can trace to a call by gtk+ > trying to do a dlopen of a pango .so. > > Two questions: > > 1. Is it normal for a statically linked application to attempt to > dlopen a shared library? > 2. Are there some g++ command line arguments necessary to forestall > this behavior in the statically linked application? > > I sure hope one of you guys can point me in the correct direction on this. > > Thanks, > > Bob Caryl > _______________________________________________ > gtkmm-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtkmm-list > _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
