Re: [Devel] Bad problems due to function renaming

[Owen Taylor]

On Thu, 2003-11-13 at 05:57, Tim Ruehsen wrote:
> Hi Werner,
> 
> Am Donnerstag, 13. November 2003 11:42 schrieb Werner LEMBERG:
> > > Now I ask you, the developers to put in the old function names (like
> > > FT_Seek_Stream) into freetype 2.1.x.  In addition to the new ones.
> > > I think it is not that much work.  The old functions are just
> > > calling the new ones.  All the version conflicts then could be
> > > resolved by upgrading freetype.
> >
> > AFAIK, FT_Seek_Stream was *never* a public function!  Consequently,
> > programs shouldn't use it at all.  I'm not willing to invest time to
> > handle that.  Perhaps there are volunteers to provide a solution...
> 
> Hmm... I am pretty shure these applications (mainly qt3 and pango) do not use 
> these functions directly. They use public functions which call the non-public 
> functions. This is why I can recompile these apps with freetype 2.1.x without 
> problem (if all those source rpms where build properly - which is not the 
> case, e.g. after recompiling qt3 kdm crashes, after recompiling pango one 
> libpangoxft is missing which prevents GTK apps from starting).
> 
> Just to show you the problem with libpango:
> ldd -r /usr/lib/libpangoft2-1.0.so.0
>         libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40048000)
>         libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40080000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40085000)
>         libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40088000)
>         libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x400f3000)
>         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40125000)
>         libc.so.6 => /lib/i686/libc.so.6 (0x40176000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> undefined symbol: FT_Seek_Stream        (/usr/lib/libpangoft2-1.0.so.0)
> undefined symbol: FT_Get_Short  (/usr/lib/libpangoft2-1.0.so.0)
> undefined symbol: FT_Forget_Frame       (/usr/lib/libpangoft2-1.0.so.0)
> undefined symbol: FT_Access_Frame       (/usr/lib/libpangoft2-1.0.so.0)
> undefined symbol: FT_Get_Long   (/usr/lib/libpangoft2-1.0.so.0)

Pango *does* use these symbols directly (as part of some low-level
OpenType table code.) They are clearly internal symbols, so we didn't
expect compatibility guarantees for them. 

So, yes, you may have to recompile Pango. But you won't have to
recompile apps that use Pango. Difficulties in recompiling Pango or
Qt don't really belong on this list...

Regards,
                                        Owen