4.4-beta1 installer failures on OpenBSD 3.9

Benedikt Meurer benedikt.meurer at unix-ag.uni-siegen.de
Thu May 11 11:20:15 CEST 2006


Landry wrote:
> Hello all.

Hey Landry,

You should probably write separate emails/bugreports for separate
issues, that makes it easier for people to answer the specific topics. :)

> I installed all components under /home/landry/local/xfce-4.3.90.1/ prefix.
> Here are the little bugs (?) i found, and the steps i've followed :
> - first, i had to install vte, gmake and pkgconfig packages. This is 
> _not_ a bug :)
> - Xfce installer claims dependencies on libXpm and libSM, which are 
> installed by Xorg packages. The installer _wants_ files named libSM.so 
> and libXpm.so, but on OpenBSD, libs only exists as libfoo.a and 
> libfoo.so.major.minor. There is no symlink pointing from libfoo.so to 
> libfoo.so.major.minor like on other *nix systems. I dunno if this is to 
> be considered as a bug, but i'm reporting it anyway. Maybe the installer 
> should check for the presence of libfoo.so*, and report a warning if the 
> minor/major mismatch.
> I'd like to know how libtool behaves on the creation of a library, if it 
> creates only .a and .so.minor.major versions, and if it is up to the 
> system/distro/packaging system to create the symlinks.
> The workaround here was to create the symlinks in /usr/X11R6/lib for 
> libSM.so and libXpm.so.

Yep, that's because g_module_build_name() returns "<name>.so" on OpenBSD.

That reminds me of the issue for the new installer. Jannis, how about
trying to link with the library, rather than looking for the library
file. I.e. try to compile and link a test program with -l<name>. The
platform's linker will know best how to map the <name> to a file name.

> - Then, the installer started to compile. The first crash was on the 
> compilation of libexo, with error "checking if we build python bindings 
> .. no interpreter found.". apparently, ./configure doesn't check if 
> there is a python interpreter, and python isn't declared as a dependency 
> for libexo.

Right, it's a soft-dependency.

> - second crash in libexo compilation was with the following :
> 
> if /bin/sh ../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. 
> -I. -I.. -I.. -DEXO_API_SUBJECT_TO_CHANGE -DEXO_COMPILATION 
> -DG_LOG_DOMAIN=\"exo\" 
> -DLIBEXECDIR=\"/home/landry/local/xfce-4.3.90.1/libexec\" 
> -DLIBEXO_VERSION_API=\"0.3\" 
> -DPACKAGE_LOCALE_DIR=\"/home/landry/local/xfce-4.3.90.1/share/locale\" 
> -I/home/landry/local/xfce-4.3.90.1/include  -I/usr/X11R6/include 
> -I/usr/X11R6/include -DXTHREADS -D_REENTRANT 
> -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include 
> -I/usr/X11R6/include -I/usr/local/include/atk-1.0 
> -I/usr/local/include/pango-1.0 -I/usr/X11R6/include/freetype2 
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -I/home/landry/local/xfce-4.3.90.1/include/xfce4 
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -I/home/landry/local/xfce-4.3.90.1/include  -I/usr/X11R6/include 
> -I/usr/X11R6/include -O2 -pipe -DG_DISABLE_CAST_CHECKS 
> -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -MT libexo_0_3_la-exo-marshal.lo 
> -MD -MP -MF ".deps/libexo_0_3_la-exo-marshal.Tpo" -c -o 
> libexo_0_3_la-exo-marshal.lo `test -f 'exo-marshal.c' || echo 
> './'`exo-marshal.c; \
> then mv -f ".deps/libexo_0_3_la-exo-marshal.Tpo" 
> ".deps/libexo_0_3_la-exo-marshal.Plo"; else rm -f 
> ".deps/libexo_0_3_la-exo-marshal.Tpo"; exit 1; fi
>   gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -DEXO_API_SUBJECT_TO_CHANGE 
> -DEXO_COMPILATION -DG_LOG_DOMAIN=\"exo\" 
> -DLIBEXECDIR=\"/home/landry/local/xfce-4.3.90.1/libexec\" 
> -DLIBEXO_VERSION_API=\"0.3\" 
> -DPACKAGE_LOCALE_DIR=\"/home/landry/local/xfce-4.3.90.1/share/locale\" 
> -I/home/landry/local/xfce-4.3.90.1/include -I/usr/X11R6/include 
> -I/usr/X11R6/include -DXTHREADS -D_REENTRANT 
> -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include 
> -I/usr/X11R6/include -I/usr/local/include/atk-1.0 
> -I/usr/local/include/pango-1.0 -I/usr/X11R6/include/freetype2 
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -I/home/landry/local/xfce-4.3.90.1/include/xfce4 
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -I/home/landry/local/xfce-4.3.90.1/include -I/usr/X11R6/include 
> -I/usr/X11R6/include -O2 -pipe -DG_DISABLE_CAST_CHECKS 
> -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -MT 
> libexo_0_3_la-exo-enum-types.lo -MD -MP -MF 
> .deps/libexo_0_3_la-exo-enum-types.Tpo -c exo-enum-types.c  -fPIC -DPIC 
> -o .libs/libexo_0_3_la-exo-enum-types.o
> In file included from ../exo/exo.h:34,
>                   from exo-enum-types.c:6:
> /usr/local/include/glib-2.0/glib/gi18n.h:23:21: libintl.h: No such file 
> or directory
> 
> libintl.h is located in /usr/local/include, so to correct this, i had to 
> export CPATH=/usr/local/include before launching the installer. I 
> exported too PKG_CONFIG_PATH=/usr/local/lib/pkgconfig.

This is a problem with glib. GLib public headers include libintl.h, but
pkg-config --cflags glib-2.0 does not add the required include path.
Please file a bug report to GLib.

> xfdesktop didn't manage to load the menu, the menu panel plugin didn't 
> work, i couldn't add some plugins to the panel, and xfce-mcs-settings 
> didn't found the mcs-plugins. That was the same .so problem, so i 
> manually symlinked all the libs doing this in 
> $base/lib/xfce4/{modules,mcs-plugins,panel-plugins} :
> for i in `ls *.so*`; do ln -s $i `echo $i | sed -e's/.0.0//'` ; done

Same issue as described above.

> The only thing that embarasses me is the .so vs .so.major.minor problem. 
> I don't know if this "issue" comes from xfce, from libtool or from 
> OpenBSD settings.

A bit of everything. Mainly libtool shouldn't add major.minor, when
-module option is specified. For some reason it does not work properly
on OpenBSD.

> Thanks for this great piece of software !!!
> Landry

Benedikt



More information about the Xfce4-dev mailing list