xfce4-dev-tools [was: dbh/xffm conflict]
Benedikt Meurer
benedikt.meurer at unix-ag.uni-siegen.de
Sat Jan 29 19:48:27 CET 2005
edscott wilson garcia wrote:
>>FYI it breaks everything because it links libdbh-1.0.21.1.0.0 to libdbh
>>while most apps expect libdbh-1.0.so.1 or libdbh-1.0.so (as the name is
>>dbh-1.0)
>
> I just put release 22 at sf. I've removed gcc specifics and fix the
> error where the library release was specified as 1.0.21 instead of the
> correct 1.0. But that is minor. The .so issue goes farther and also
> affects the xfce libraries as well.
>
> With xfce4-dev-tools the .so is dropped from the filenames. IOW,
> libdbh-1.0.so is now plain libdbh-1.0 and libdbh-1.0.so.1.0.0 is now
> libdbh-1.0.1.0.0. (libdbh-1.0.21.1.0.0 was an abortion).
>
> The .so is being dropped from xffm libraries created with the use of the
> xfce4-dev-tools and libxfce4util libraries. I suppose libxfcegui4 too,
> but I haven't checked. I don't know if Benny intended it this way or if
> it a bug. Benny?
>
> BTW, dropping ".so" does not seem to affect things on my box.
Thats definetly not the expected behaviour, but its pretty unrelated to
the xfce4-dev-tools itself, since the library extension is determined by
libtool at configure time and then written into the script libtool
(which is also autogenerated). Just run configure, and then use
grep '^shrext_cmds=' libtool
to see what libtool detected for your system.
The site
http://people.debian.org/~keybuk/libtool-missing_so.html
contains some bits and pieces of informationen concerning libtool problems.
My bet is that your libtool.m4 (atleast the one thats chosen by
aclocal), doesn't match your libtoolize. Please check that.
> regards,
> Edscott
HTH,
Benedikt
More information about the Xfce4-dev
mailing list