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