Re: More statically linked adventure

[Jonathon Jongsma <jonathon jongsma gmail com>]

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 <bob fis-cal com> 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
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>