Spec Url: http://math.ifi.unizh.ch/fedora/spec/gauche-gtk.spec SRPM Url: http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-gtk-0.4.1-5.fc5.src.rpm Description: Gauche extension module to use GTK.
http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-gtk-0.4.1-6.fc5.src.rpm
I'm getting a build failure in mock: checking for X... no configure: creating Gauche-gtk.gpd *** ERROR: Compile Error: can't find dlopen-able module "srfi-1-lib" "/usr/bin/gauche-package":37:(use srfi-1) Stack Trace: _______________________________________ This repeats with the same error a few times; I'll attach a build log.
Created attachment 128549 [details] Log from failing build in mock (development, i386)
Note, the failure is identical when building for FC5-i386, but is somewhat different when building for FC5-x86_64. There it seems to get fully through the configure phase and most of the way through compilation and then dies: /usr/bin/ld: gauche-gtk.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared o bject; recompile with -fPIC gauche-gtk.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [gauche-gtk.so] Error 1 None of these change when I turn of parallel make, BTW.
The failure on i386 is due to inconsistent naming of the arch directory in gauche, there are both i386-redhat-linux-gnu and i686-redhat-linux-gnu, so that the so files could not be found. I patched gauche, so that the both are the same. This problem doesn't occur on x86_64. The problem you reported is probably not from gauche but from gauche-gtk itself. I will look at it, probably missing -fPIC when compiling the sources, just as the error message says. Gauche is being rebuild. Please check it out as soon as it gets to the repositories and try the following: - start gosh - enter "(use srfi-1)" this should now return #<undef> and no error any more.
Building on i386 with the fixed gauche gets further, but then fails: gcc -DHAVE_CONFIG_H -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I'/usr/lib/gauche/0.8.7/include' -fomit-frame-pointer -ma rch=i686 -DUSE_I686_PREFETCH `pkg-config --cflags gtkglext-1.0` -c -o glgdGraph.o glgdGraph.c In file included from /usr/include/pango-1.0/pango/pangofc-font.h:25, from /usr/include/pango-1.0/pango/pangoft2.h:29, from glgd.h:21, from gauche-glgd.h:26, from glgdGraph.c:12: /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory and then there are cascading errors off of that; I'll attach the build log if you're interested. I thought the problem might be a missing BR: freetype-devel, but no luck. usr/include/freetype2/freetype/config/ftheader.h does exist. It almost seems as if a call to pkgconfig --cflags freetype2 needs to be made. I'm not really sure what's up. I know you wouldn't have submitted these packages if they didn't build for you, but I'm just having no luck at all building them. Are you able to do mock builds? I'm pretty sure my build setup is working OK, so you should be able to see the same failures I'm seeing.
You are right: mock build fails. However outside of mock the build succeeds. I don't know what happens here, I compared both build logs and they differed (except for the build paths) only the moment the build fails! I included buildrequires for some X libraries (configure checks for them), but nothing changes (package at the same place). The only thing that I noticed is, that some packages retrieved by mock are older than the corresponding packages I have installed locally (both mock and local are FC5), for example cairo = 1.0.4 locally but 1.0.2 in mock, and gtk = 2.8.15 in mock vs 2.8.17 locally.
Created attachment 128648 [details] local build log
Created attachment 128649 [details] mock build log
You can use meld to compare the two logs and see that they hardly differ up to the break down.
(In reply to comment #10) > You can use meld to compare the two logs and see that they hardly differ > up to the break down. I don't think it's a mock issue; I can reproduce this failure with a local FC5 build. Still investigating. What I don't understand is how the build can possibly succeed without -I/usr/include/freetype2 on the failing command. What is the output of: pkg-config --cflags gtkglext-1.0 on your local systems? Here, I get: -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/atk-1.0 which does not include the necessary directory.
Mea culpa! On my system I had linked /usr/include/freetype2 to /usr/include/freetype. When I removed the link, the build doesn't work anymore. So I defined CFLAGS to use the freetype pkg-config flags in the spec file. Now it builds in mock too. However, this means, that there is a bug in the pkg-config for pango: it returns only -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include, but since the pango header file pangofc-font.h includes ft2build.h, the include path for freetype must be added too. Updated package: http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-gtk-0.4.1-7.fc5.src.rpm
(In reply to comment #12) > However, this means, that there is a bug in the pkg-config for > pango: it returns only -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include, but since the pango header file > pangofc-font.h includes ft2build.h, the include path for freetype > must be added too. I thought it would be something along those lines but was a bit confused by the fact that pango-devel includes five .pc files, and the pangoft2.pc and pangoxft.pc files do have the necessary include path. So perhaps it's gtkglext-1.0.pc or gdkglext-x11-1.0.pc that should require pangoft2 or pangoxft?
Ah, I see. IMHO this splitting in five .pc files is very bad. gtkglext probably dates from a time when pango had just one .pc file. BTW I also added -fPIC to CFLAGS, otherwise the shared object file gets a TEXTREL and loading it with selinux enabled will not work.
(In reply to comment #13) > So perhaps it's gtkglext-1.0.pc or gdkglext-x11-1.0.pc that should require > pangoft2 or pangoxft? Hmm, does anybody see any direct dependency between gtkglext and pangoft2 or pangoxft? At least, I don't see any, so I am inclined to think there might be a missing dep anywhere underneath. Or am I missing something?
(In reply to comment #15) > At least, I don't see any, so I am inclined to think there might be a missing > dep anywhere underneath. Or am I missing something? No, it is glgd.h that includes <pango/pangoft2.h>.
(In reply to comment #15) > (In reply to comment #13) > > So perhaps it's gtkglext-1.0.pc or gdkglext-x11-1.0.pc that should require > > pangoft2 or pangoxft? > Hmm, does anybody see any direct dependency between gtkglext and pangoft2 or > pangoxft? > > At least, I don't see any, so I am inclined to think there might be a missing > dep anywhere underneath. Or am I missing something? As it happens, I think Gérard has done exactly the right thing. This package is explicitly calling for ft2 support by including pango/pangoft2.h from glgd.h. This only happens if the --enable-glgd-pango option is passed to the configure script, and HAVE_GLGD_PANGO gets set. So it's this client, and not a problem stemming from a missing dep somewhere down the tree. If there's a bug, I suggest that it's that --enable-glgd-pango in this package should also pull in the pangoft2 pkgconfig file for include directory settings.
OK, now we're getting somewhere. Rawhide still looks broken to me, but builds in FC5, i386 and x86_64 succeed and I ran through the examples on x86_64 with no problems. rpmlint has a couple of complaints: W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages W: gauche-gtk doc-file-dependency /usr/share/doc/gauche-gtk-0.4.1/examples/glgd/run /bin/sh The problem with the first warning is that it will set off various rootkit detection programs and is generally a bad idea, but I'm not sure if it would be feasible to change where gauche looks for its packages. I'm inclined to say this isn't a blocker, but if it's not difficult to make gauche look in "packages" instead of ".packages" then I think it would be best if you could do so. The second is simply that the doc file is executable, which is generally considered a bad idea although in this case the dependency doesn't cause problems. I would suggest that you just chmod -x examples/glgd/run. Review: * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * license field matches the actual license. * license is open source-compatible; text is included in the package. * source files match upstream: 18356efab446b9524be8371a3b852a6a Gauche-gtk-0.4.1.tgz 18356efab446b9524be8371a3b852a6a Gauche-gtk-0.4.1.tgz-srpm * latest version is being packaged. * BuildRequires are proper. * package builds in mock (FC5, i386 and x86_64). O rpmlint has excusable errors. * final provides and requires are sane. O shared libraries are present, but they are internal to Gauche and so ldconfig doesn't need to be called. * package is not relocatable. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. O file permissions are appropriate, exceot for an executable docfile. * %clean is present. O %check is not present; no test suite upstream. * no scriptlets present. * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * no headers. * no pkgconfig files. * no libtool .la droppings. APPROVED, but please consider the two issues above before checking in.
(In reply to comment #18) > OK, now we're getting somewhere. Rawhide still looks broken to me, but builds > in FC5, i386 and x86_64 succeed and I ran through the examples on x86_64 with no > problems. That sounds good! > W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages > W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages I understand the point. In fact the directory ".packages" is coded in the file package.scm of gauche. The problem is that ".packages" is hardcoded in the makefiles of the gtk and gl packages. This means that changing the directory will propagate down to the packages. I would rather leave it as it is for now. > W: gauche-gtk doc-file-dependency > /usr/share/doc/gauche-gtk-0.4.1/examples/glgd/run /bin/sh This file should be deleted anyway. BTW, the examples using OpenGL only run when gauche-gl is installed. Probably gauche-gtk should depend on gauche-gl then. Should we wait for the gauche-gl to be ready?
> I understand the point. In fact the directory ".packages" is coded > in the file package.scm of gauche. The problem is that ".packages" > is hardcoded in the makefiles of the gtk and gl packages. Isn't it just one line in each makefile, though? I don't think it's a blocker, but it's probably easier to change it now than to wait until later when you'd have to coordinate releases of all three packages. > BTW, the examples using OpenGL only run when gauche-gl is installed. > Probably gauche-gtk should depend on gauche-gl then. Surely not for an example. If you want to be complete, you can add a note in that directory indicating that the -gl package needs to be installed in order for them to work. I'll be working on gauche-gl soon in any case.
(In reply to comment #20) > Surely not for an example. If you want to be complete, you can add a note in > that directory indicating that the -gl package needs to be installed in order > for them to work. The module gl from gauche-gl is in fact imported from the module glgd which is part of gauche-gtk, so I would say that gauche-gl is required for gauche-gtk to provide the full functionality.
Were you going to check this in? I see no reason not to add a dependency on gauche-gl if it makes sense to do so.
Ok, I thought there would be an further comment about this issue.
Built on FC-4, FC-5 and FC-6. Added to owners.list. Thanks for the review!