On Wed, Oct 29, 2008 at 10:21 PM, Adriaan de Groot <groot at kde.org> wrote: > On Wednesday 29 October 2008, Ben Taylor wrote: >> 1) it's geared only for SXCE, cause it will bomb out on _is64, >> but S10 has a proper glib-2.0 and gstreamer from FOSS. > > I don't understand here. What is bombing? Where?
compiling. It's bringing in the includes from /usr/include/glib-2.0 on S10 instead of /opt/foss/include/glib-2.0. I recognize this problem because phonon emits the same errors that qt-4.4.1 did until I passed the proper glib/gstreamer includes to it in the configure script. I can send you the log. AFAICT, the glib and gobject Cmake files aren't properly resolving FOSSglib and are in fact sending in the Solaris defaults. > I might guess your meaning that linking in 64-bit mode is pulling in the > 32-bit gstreamer and then failing. I see this in FOSSqt on Dillon right now, > with this bit in the log: Well, I figure that the exit if _is64 is pretty clear, but I also think that is only appropriate for SXCE, unless we also build glib-2.0 and gstreamer on there as well.. > GSTREAMER_LDFLAGS: -L/usr/lib/amd64 -lgstreamer-0.10 > > This is quite bogus, since there is no 64-bit gstreamer installed; there *is* > a 32-bit version installed. This is a case of pkg-config doing bogus things; > something in my environment (PKG_CONFIG_PATH) is damaging the output. Right, and I understand that this isn't in SXCE. On S10 with FOSS, we do have 64-bit glib and gstreamer libraries. >> 2) no fix for glib-2.0 look up on S10. I fixed this in the original >> dude Phonon and am retesting what I had from a couple >> of months ago. > > Probably one of the patches that fell between the cracks. Is this again about > the position of -L/usr/lib? No. See above. It appears to be some sort of Cmake resolution issue. I "suspect" that if I passed in the proper glib and gobject includes and such during configure/build, that it may work. But I'm still spining up on the new infrastructure. >> 3) I have no clue how I'm supposed to fix this given that it >> downloads a tarball.... Dude I could work with. some >> mention on techbase might be nice on how to patch >> stuff that doesn't work so you don't lose the work.... > > Assuming you don't wipe out all of ~/packages/SOURCES (or wherever you have > pkgtool configured for) regularly, it will download the pristine upstream > source tarball once. Alternateively, you can add --with-dude to the > PKGTOOL_ARGS variable in Makefile.config and it will assume you are rolling > tarballs into ~/packages/SOURCES from Dude yourself. > > For the build, there are three files: > - the source tarball > - the Solaris/ directory for the package > - the Solaris/libtool file > > By unpacking those three, the hg-based stuff re-creates exactly what's in > Dude -- the pristine sources, the Solaris/ directory, and our own libtool. If > you are making changes to the source, then I would recommend > adding --with-dude and rolling your own tarballs (with whatever worked in > SPECS/). As an alternative, you can cd to ~/packages/BUILD/<package>/<arch>; > you will find in the Solaris/ directory a file 'environment' which you can > source. This is exactly the environment as it is set up for the build. Ah. Thank you. That was the part I didn't have, and didn't see on techbase. Ben
