GNOME Bugzilla – Bug 157536
pango doesn't compile on Sparc/Solaris using Forte (cc)
Last modified: 2011-02-18 16:09:58 UTC
Try to compile with Forte (cc) - it will fail with something like (undefined symbol) g_string_insert_c in ottest.o Fix (patch, actually): See http://mail.gnome.org/archives/gtk-i18n-list/2004-June/msg00020.html I can confirm this does the trick, even for 1.6.0 which I tried to compile. Patching the Makefile isn't nice, so a real fix would be great. I'm just wondering why no-one noticed this one since the posting appeared on a gnome mailing list...
I'm simply not going to hack Pango because Glib's configure tests didn't work properly on a system. If including glib.h is causing code to be generated in your object files, that's a serious problem.
This could be related to bug 149907
*** Bug 162599 has been marked as a duplicate of this bug. ***
Consider the following code: int func2 (int); static inline int func1 (void) { return func2 (1); } int main (void) { int i = 1; } The following compilers *will not* create an undefined entry in the inline.o object file: SGI MIPSPro 7.4.2m Tru64 UNIX DTK V6.5-207 IBM VisualAge Compiler v6, v7 The following compilers *will* create an undefined entry: Sun Forte Developer 6 Compiler (C 5.3) Sun One Studio 8 Compiler (C 5.5) HP-UX 10.20 C Compiler (B.10.20.09) HP-UX 11.x C compiler (B.11.11.08) This looks like a compiler bug to me. Old compilers like the ones for HP-UX 10.20 will never get fix (but it doesn't run ottest anyway as varargs aren't available). I'll report the bug to Sun. Dunno if they'll fix in the older compilers though.
I think we need to fix the tests in configure.in so that G_CAN_INLINE doesn't end up set if an unused inline function defintion results in generated code. What G_CAN_INLINE is supposed to indicate really isn't whether local inline functions work or not ... the definition of inline to empty in gutils.h takes care of that. What it is supposed to indicate is whether we can put inline functions in header files. Using something like your test above with a AC_LINK_IFELSE should work. (It could, of coursem depend on optimization level but getting it right with autoconf's default optimization level is a start.)
How about we ditch the G_CAN_INLINE machinery in glib/gutils.h and do it all at configure-time? We'd have a G_CAN_INLINE in glibconfig.h. I'd essentially leave all of the existing INLINE machinery in configure.in in place and add G_CAN_INLINE to the mix.
Created attachment 35326 [details] [review] Proof-of-concept patch I haven't tested this yet but how's it look as a proof-of-concept?
Patch looks good to me from visual inspection.
Ok, I've tested this patch on Solaris 2.6-9/SPARC and HP-UX 10.20, 11.x. It works fine.
The patch misses a g_can_inline=$g_can_inline next to g_have_gnuc_visibility=$g_have_gnuc_visibility And I wonder whether gutils.h shouldn't be further simplified. There are still instances of #undef G_CAN_INLINE, and there is also the question why we define G_INLINE_FUNC as extern if inlining doesn't work (bug 149907)
Another question is about the use of G_CAN_INLINE in gstring.h: It looks slightly dubious to me that the ABI depends on G_CAN_INLINE there. Shouldn't we do the same thing we do for gutils.h there ?
Created attachment 35392 [details] [review] Updated patch with g_can_inline=$g_can_inline
OK, went through the patch in some more detail: - With the revised patch, the gutils.h machinery looks fine. I don't think it's further simplifiable; morten is likely right that G_INLINE_FUNC should be empty for G_IMPLEMENT_INLINES. There's also another issue that C99 defines 'extern inline' in a way that is incompatible with the old GCC definition of it, so the 'if defined (__GNUC__) && defined (__OPTIMIZE__)' switch that picks 'extern inline' probably should be removed. But both of those are unrelated to this change. - The patch unconditionally defines G_CAN_INLINE for __cplusplus ... does the C++ spec guarantee that a 'static inline' function won't have code emitted if the definition is never used? - Might be good to use something more distinct that func2() in the test. Maybe glib_test_func2() or something. - Before committing, we should definitely check that G_CAN_INLINE is getting defined and stuff is getting inlined with GCC.
I checked that G_CAN_INLINE gets defined. What is your take on the gstring.h use of G_CAN_INLINE ?
2005-01-04 Matthias Clasen <mclasen@redhat.com> Fix the inlining magic. (#157536, Jens Hatlak, and #149907, Morten Welinder) * configure.in: Define G_CAN_INLINE in glibconfig.h * glib/gutils.h: Streamline the inlining magic a bit, don't use extern when implementing the non-inlined version.
*** Bug 136425 has been marked as a duplicate of this bug. ***