4.2.0-2 is in CVS but not build, the current build version -devel doesnot install as it requires Xfree86-devel (how old is that?) Please build the current CVS version.
Is there a particalar reason to not build it? Ifso, what? maybe I can help.
Hello Hans, thanks for your offer to help me with the latest upstream allegro build. See this after building this version of allegro on x86_64: gcc -s -Wl,--export-dynamic -o setup/setup obj/unix/setup.o -Llib/unix -lalleg-4.2.0 -lalleg_unsharable -lm lib/unix/liballeg-4.2.0.so: undefined reference to `_colorconv_rgb_scale_5x35' lib/unix/liballeg-4.2.0.so: undefined reference to `_colorconv_indexed_palette' lib/unix/liballeg-4.2.0.so: undefined reference to `_colorconv_rgb_map' collect2: ld returned 1 exit status make: *** [setup/setup] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.11763 (%build) what prevents me from successfully building the package.
Hmm, Strange I'm on a rawhide x86_64 system which is a couple of days old (currently busy upgrading) and the FE CVS devel version builds fine for me. You get this error in plague / mock only or locally too?
More info: [hans@shalem allegro-4.2.0]$ grep -r colorconv_rgb_map src gives: src/misc/colconv.c:unsigned char *_colorconv_rgb_map = NULL; And its a global variable in src/misc/colconv.c, maybe colconv.o doesn't get linked in the .so file for some reason?
plague gives the error. The build works for me on my i386 rawhide box as well. Yes, it's a linking problem. Note that the new allegro is impossible to build successfully with %{?_smp_mflags} due to bad dependencies, what shows something's odd with the dependencies.
2 Questions: 1) do you have a pointer to the plague build logs? 2) may I muck around in CVS-devel branch and request builds to test any fixes I come up with (and thus if I succeed cause a package to be pushed to the FE devel tree)?
I just tried to rebuild it again and here we go with the log: http://buildsys.fedoraproject.org/logs/fedora-development-extras/3120-allegro-4.2.0-2/x86_64/ Feel free to mock around and request builds if needed. Thanks.
Update: I'm closing in on the problem pretty fast. I'm sure we are missing some modular Xorg BuildReqs, colconv.c is in makefile.lst as part of ALLEGRO_SRC_X_FILES, so appearantly, The X part of allegro is not being build.
Closing even more, the aclocal.m4 uses an AC macro called: AC_PATH_X this expands to a dirty piece of bash in ./configure which: -first checks if an X-include and an X-lib dir have been given on the ./configure cmdline -then checks what Imake thinks the correct paths are and then checks if the Imake given include dir contains X11/Xos.h, which come from xorg-x11-proto-devel. -if xmkmf is not installed or Imake has wrong settings then it checks for X11/Intrinsic.h which comes from libXt-devel -if xmkmf is not installed or Imake has wrong settings then it checks for -lXt, which again comes from libXt-devel So there are 3 solutions: -pass X include and X lib dir options on the cmdline (ugly) -buildreq xorg-proto-devel (which we must do anyways to get SHM support) and require xmkmf (ugly) -buildreq libXt-devel, of which I wonder if the rest of allegro needs at all, then again its only a BR. Also it will need more BR's for things like SHM, Xcursor support etc. Unfortunatly I have togo now, I'll work on this some more tonight or tomorrow. Let me know which solution you prefer from the above three
IMO the libXt-devel BuildRequires is the best way to follow. I noticed you have issues with building allegro, so I requested another build today to see whether it works today or not.
I already opted for libXt-devel and a fix has been committed to CVs, but as we both have noticed, the buildsys currently is (still) down. BTW I also fixed up the requires for allegro-devel. On a related note, allegro can use / compile in a jack audio plugin, but then we should add a BuildReq for jack, jack is in FE nowadays I believe. If we do this it might be a good idea to put this in a subpackage as to not drag in jack with the default allegro package, the same could be argued for esd and arts support btw, although those get dragged in by so many packages that one more package doesn't matter much. Also what do you think about bug 178383?
Now the buildsys is back up I've managed to successfully do a build, closing. p.s. Could you take a look at bug 178383?