buggnokii - Bugs: bug #37192, gnokii-0.6.31 build failure with...


You are not allowed to post comments on this tracker with your current authentication level.

bug #37192: gnokii-0.6.31 build failure with clang (undefined symbols)

Submitter:  Hanspeter Niederstrasser <nieder>
Submitted:  Sat 25 Aug 2012 04:16:41 PM UTC
Category:  build Severity:  3 - Normal
Item Group:  installation Status:  Fixed
Privacy:  Public Assigned to:  ja
Open/Closed:  Open

Sun 26 Aug 2012 10:22:08 PM UTC, comment #3: 

Hello Pawel.

I see three reasons for use of inline function.
The first one is when you have a function called many times in cycle and you want for performance reason to strip out the opening and closing sequence for function calling.

The second reason is a small function when the opening and closing sequence for function calling is bigger then a body of the function. GCC can do it automagicaly with -finline-small-functions (included in -O2 switch).

The third reason for inline is when you split a bigger function to small functions and these small functions are called only on one place in program. GCC can do it automagicaly with -finline-functions-called-once.

I looked to smsd and there are only 4 inline functions.

InsertEvent(), FreeElement() and FreeArray () are reasonable small functions on the first look and in case of FreeElement() there is also a performance reason.

RemoveEvent() looks to be bigger but when you look at the code and forgot the long variables and functions names, it is very simple few lines function. And it is called only on one place in a cycle.

I didn't looked to xgnokii source for many years.
I was little bit surprised when I saw result of grep. But most of them are 1 to 3 lines functions. The bigger function are:

Above functions are called only on one place in code and are called frequently.


Above function is called only on one place in code

And following functions need not be inline:

Jan Derfinak <ja>
Group Member
Sat 25 Aug 2012 09:08:38 PM UTC, comment #2: 

OK, I've read the link with debian logs. So that should be fixed with current git. However I did just the necessary changes.

Jan, there is a lot of code in smsd and in xgnokii that is marked as inline. Is there any particular reason for that? There are, in some cases, large chunks of code to be inlined. I may be missing something but it does not necessarily look like a good idea to me.

Pawel Kot <pkot>
Group administrator
Sat 25 Aug 2012 08:19:45 PM UTC, comment #1: 

For now I can advice not to use clang then. I think the code is just fine and there is some confusion within the compiler for an unknown reason to me. I think it would be more useful to report it to clang people.

Pawel Kot <pkot>
Group administrator
Sat 25 Aug 2012 04:16:41 PM UTC, original submission:  

When using clang as the compiler, gnokii 0.6.31 fails to build with this error:

libtool: link: gcc -I../include -D_THREAD_SAFE -I/sw/include/gtk-2.0 -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/sw/include/cairo -I/sw/include/pango-1.0 -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/freetype2 -I/sw/include -I/usr/X11R6/include -I/usr/X11/include -DGTK_ENABLE_BROKEN -DLOCALEDIR="/sw/share/locale" -g -O2 -Wall -o .libs/xgnokii xgnokii-xgnokii.o xgnokii-xgnokii_common.o xgnokii-xgnokii_contacts.o xgnokii-xgnokii_sms.o xgnokii-xgnokii_netmon.o xgnokii-xgnokii_dtmf.o xgnokii-xgnokii_cfg.o xgnokii-xgnokii_speed.o xgnokii-xgnokii_xkeyb.o xgnokii-xgnokii_calendar.o xgnokii-xgnokii_logos.o xgnokii-xgnokii_xring.o xgnokii-xgnokii_lowlevel.o xgnokii-xgnokii_data.o  -L/sw/lib /sw/lib/libgtk-x11-2.0.dylib /sw/lib/libgdk-x11-2.0.dylib /sw/lib/libatk-1.0.dylib /sw/lib/libgio-2.0.dylib /sw/lib/pango-ft219/lib/libpangoft2-1.0.dylib /sw/lib/libgdk_pixbuf-2.0.dylib /sw/lib/pango-ft219/lib/libpangocairo-1.0.dylib /sw/lib/libcairo.dylib /sw/lib/pango-ft219/lib/libpango-1.0.dylib /sw/lib/freetype219/lib/libfreetype.dylib /sw/lib/fontconfig2/lib/libfontconfig.dylib /sw/lib/libgobject-2.0.dylib /sw/lib/libgmodule-2.0.dylib ../common/.libs/libgnokii.dylib -L/usr/X11/lib -lXpm -lX11 /sw/lib/libiconv.dylib /sw/lib/libusb.dylib -lpthread /sw/lib/libical.dylib /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib ../common/data/.libs/libDATA.a
Undefined symbols for architecture x86_64:
  "_GUI_HideAbout", referenced from:
      _main in xgnokii-xgnokii.o
  "_CloseLogosWindow", referenced from:
      _logosMenuItems in xgnokii-xgnokii_logos.o
ld: symbol(s) not found for architecture x86_64

(it says gcc, but gcc here is a wrapper to clang)

This failure does not occur when the compiler is changed to llvm-gcc.  Debian sees a similiar failure in their clang logs: http://clang.debian.net/status.php?version=3.0&key=UNDEF_REF

OS X 10.7, clang version 3.1 (as well as Apple's modified 2.1)

Hanspeter Niederstrasser <nieder>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ja (Posted a comment)
  • -email is unavailable- added by pkot (Posted a comment)
  • -email is unavailable- added by nieder (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-08-25 pkot StatusNone Fixed
        Assigned toNone ja

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code