libffi conflicts with GCC Java
bruce.dubbs at gmail.com
Tue Nov 30 18:45:55 PST 2010
Randy McMurchy wrote:
> Randy McMurchy wrote these words on 11/30/10 18:18 CST:
>> The java language in the GCC compiler set also installs a libffi.
>> Unfortunately it is libffi.so.4.0.1. If you install GCC with the java
>> language and you already had the libffi package installed with other
>> programs and libraries linked to libffi.so.5, when the GCC overwrites
>> it with libfffi.so.4, things will get ugly.
> Actually, this is not true. If a package linked to the so.5 version of
> libffi, it will always be linked to that version. As long as it exists,
> things are okay. However, the .so file itself that points to either the
> .so.4 or .so.5 (depending on which flavor of libffi) will be overwritten.
> Does this present a problem if some packages are linked to one version
> of libffi and other packages link to another version?
Let me relate a similar problem. I am doing development and have used
libqca.so which points to libqca.so.2.0.1. Slackware 12 uses
/usr/lib/libqca.so.1 for (I think) kwallet and KDE3. They also has some
weird directory symbolic links:
/usr/X11R6/lib -> ../lib
Qt4's qmake automatically inserts -L/usr/X11R6/lib *before* user
specified libraries (yes it's a bug and I reported it, but Nokia won't
fix it), there was no way for the -lqca option to find the right version
of the library without hand editing the Makefile.
What I did was rename the .2 version of the library libqca.so to
libqca2.so on that development system and specified -lqca2 in the qt
profile. That worked, but the combination of weird directory symlinks
and the bug in qmake created a problem that was fairly difficult to
debug and even then relatively tricky to fix.
The real solution would have been to change the OS, but some people
don't want to go through that.
>> What is the best way to mention this in the book? My thoughts are to
>> put a note in the libffi package saying to the effect "If you have any
>> thoughts at all about installing the java language from the GCC package,
>> do not install this package, instead, install the GCC java now."
> For now, I don't think anything needs to be added to the book unless we
> know that having packages linked to both versions (some to one version,
> others to the other version) is a conflict.
More information about the blfs-dev