Openmoko Bug #2191: /opt/Qtopia/plugins/phonevendors/libficgta01vendor.so is missing symbol _ZN13QModemService17setDefaultCharsetERK7QString

[Openmoko Public Trac]

#2191: /opt/Qtopia/plugins/phonevendors/libficgta01vendor.so is missing symbol
_ZN13QModemService17setDefaultCharsetERK7QString
----------------------+-----------------------------------------------------
 Reporter:  xbaldauf  |          Owner:  openmoko-devel
     Type:  defect    |         Status:  new           
 Priority:  normal    |      Milestone:                
Component:  unknown   |        Version:  unspecified   
 Severity:  normal    |       Keywords:                
 Haspatch:  0         |      Blockedby:                
Estimated:            |    Patchreview:                
 Blocking:            |   Reproducible:                
----------------------+-----------------------------------------------------

Comment(by xbaldauf):

 I tracked this down to
 http://git.openmoko.org/?p=qtopia.git;a=blob;f=devices/ficgta01/src/plugins/phonevendors/ficgta01/vendor_ficgta01_p.h;h=c2cc1e33fb50bce75733f2f9a09c870f9c4307fc;hb=HEAD
 line 489 ("setDefaultCharset(DEFAULT_CHARSET);"). Presumably, this method
 called is defined in a superclass, which presumably is defined in
 "/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2". When analyzing this file,
 I found other (old) copies of that file dangling in my system (e.g.
 "/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2.disabled" and
 "/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2.danielnoethen.de") from the
 time where there was a need for patching around various problems. The pure
 existence of these libraries in turn confused "ldconfig" such that the
 symlink from "/opt/Qtopia/lib/libqtopiaphonemodem.so.4" did not point to
 ""/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2" but to
 "/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2.disabled".

 Thus, removing the files
 "/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2.disabled" as well as
 "/opt/Qtopia/lib/libqtopiaphonemodem.so.4.3.2.danielnoethen.de" and
 subsequently running "ldconfig" solved this problem.

 Thus, in the end, the conclusion is to not change files under control of a
 package management system directly, rather than that, supply replacement
 packages which will be cleanly removed once an upgrade is available.

 This bug can be closed.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2191#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac