Static builds (again)
Okay. We can take two approaches to the static linux compile:
1- requiring gtk 2.4 already be installed 2- requiring pango 1.0 already be installed
Pango does not appear to allow itself to operate as a statically compiled library. As a result, it's use of glib creates dynamic lib deps. I'm going to try to solve that, but it will still require pango dynamic libs.
I was shooting for only requiring pango, but this is getting harder and harder. My test-case is a redhat 9 box, and it really doesn't like me: /tmp/inkscape.strip: relocation error: /tmp/inkscape.strip: undefined symbol: g_type_class_add_private
So, I'm going to continue working on pango, but I think we can make an operational "static" build that requires gtk 2.4, since that's the bulk of the static lib work I've been trying to make work. Getting gtkmm hasn't been very hard. libgc has some tricks up it's sleeve, but I think I solved those.
I'm building an RPM now that basically requires gtk 2.4, but is actually my latest attempt at approach #2. I need someone with an RPM-based distro with gtk 2.4 to test it. All I have is gtk 2.0 on rh9.
On Sun, 28 Nov 2004 10:17:26 -0800, Kees Cook wrote:
1- requiring gtk 2.4 already be installed 2- requiring pango 1.0 already be installed
Once I've better tested the PowerPC and Win32 support I will be submitting a patch allowing Inkscape to use relaytool for the new GTK+ 2.4 APIs. This would reduce its dependency to just GTK 2.0 and above which I think is reasonable.
Alternatively a more verbose patch could be written to let it use dlopen and fall back, but the point of relaytool is to make using dlopen/dlsym easier and verbose.
The autopackages already download and install GTKmm, libsigc++ and libgc is being statically linked.
Currently the relocatable builds crash, apparently due to a bug in the way the BR_ macros are being used. I think the current approach of using an automatically freed TLS slot is perhaps not very intuitive so I might change binreloc to cache every unique path and free them all at process exit time. This should hopefully fix the crash as well (debugging optimized c++ is hard!).
thanks -mike
participants (2)
-
Kees Cook
-
Mike Hearn