On Sat, Aug 6, 2011 at 12:08 AM, Alex Villacís Lasso < [email protected]> wrote:
> El 02/08/11 17:38, Octavian Voicu escribió: > > When building a 32-bit wine in a 64-bit build environment with >> default glib headers (gstreamer uses glib.h), glib 64-bit types >> (such as gint64 and guint64) are not properly defined, causing >> many compiler warnings and most likely a broken winegstreamer.dll. >> >> Although both gstreamer and glib are included in the ia32-libs >> package (on Ubuntu, and possibly others), the lack of a proper >> glibconfig.h makes the gstreamer headers unusable for 32-bit >> builds. >> > My build system is a Fedora 14 x86_64, and I am affected by this. > > What is really happening is that, on my 64-bit system, both > glib2-devel.i686 and glib2-devel.x86_64 are installed: > > [alex@srv64 wine-build]$ rpm -qf /usr/lib64/glib-2.0/include/** > glibconfig.h > glib2-devel-2.26.0-2.fc14.x86_**64 > [alex@srv64 wine-build]$ rpm -qf /usr/lib/glib-2.0/include/**glibconfig.h > glib2-devel-2.26.0-2.fc14.i686 > [alex@srv64 wine-build]$ > > Instead of shipping a single header file that uses compiler or preprocessor > defines, like /usr/include/stdint.h, glib2 ships two include files, one for > each architecture. The pkg-config --cflags option does not handle the > concept of an architecture-dependent include file correctly (or at all), so > it ends up reporting the 64-bit header even for the 32-bit build. The 32-bit > header defined gint64 as signed long long, but it is defined as signed long > in the 64 bit header. Therefore the bug. > Hello, Ubuntu also has multiarch support, but it's not enabled by default so I guess it's not that widespread yet (and the legacy ia32-libs is still a dependency in many places). But this would be the proper way, having separate architecture-dependent include files like you have. I guess that can be made to work on latest Ubuntu also, but it's not that easy as an `apt-get install`. Problem is, like you noticed, tools like pkg-config don't have proper support for multiarch yet. > A workaround I am testing is to force PKG_CONFIG_PATH to the 32-bit > directory for the configure and make steps: > > [alex@srv64 wine-build]$ pkg-config --cflags gstreamer-app-0.10 > -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 > -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 > [alex@srv64 wine-build]$ PKG_CONFIG_PATH=/usr/lib/**pkgconfig pkg-config > --cflags gstreamer-app-0.10 > -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 > [alex@srv64 wine-build]$ > > Is there any standard/known way of automating this? > I guess you could specify your own PKG_CONFIG_PATH when running configure, like this (which is probably what you do already): PKG_CONFIG_PATH=/usr/lib/**pkgconfig ./configure A proper fix would be a patch to configure.ac to detect the correct PKG_CONFIG_PATH for the target architecture. There is also a proposed change [1] to pkgconfig to allow you to specify the host system type for cross-compiles, but I'm not sure what the status of that is. Octavian
