Bug 178245 - 4.2.0-2 is in CVS but not build
4.2.0-2 is in CVS but not build
Product: Fedora
Classification: Fedora
Component: allegro (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-01-18 14:53 EST by Hans de Goede
Modified: 2013-07-02 19:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-24 06:10:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-01-18 14:53:27 EST
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.
Comment 1 Hans de Goede 2006-01-19 17:37:22 EST
Is there a particalar reason to not build it? Ifso, what? maybe I can help.
Comment 2 Jindrich Novy 2006-01-20 07:51:49 EST
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.
Comment 3 Hans de Goede 2006-01-20 08:29:38 EST

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?
Comment 4 Hans de Goede 2006-01-20 08:33:38 EST
More info:
[hans@shalem allegro-4.2.0]$ grep -r colorconv_rgb_map src

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?
Comment 5 Jindrich Novy 2006-01-20 08:52:10 EST
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.
Comment 6 Hans de Goede 2006-01-20 08:56:54 EST
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)?
Comment 7 Jindrich Novy 2006-01-20 09:21:26 EST
I just tried to rebuild it again and here we go with the log:


Feel free to mock around and request builds if needed. Thanks.
Comment 8 Hans de Goede 2006-01-20 09:48:21 EST

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.
Comment 9 Hans de Goede 2006-01-20 10:00:46 EST
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
-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 
-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
Comment 10 Jindrich Novy 2006-01-21 02:31:05 EST
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.
Comment 11 Hans de Goede 2006-01-21 03:04:04 EST
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?
Comment 12 Hans de Goede 2006-01-24 06:10:13 EST
Now the buildsys is back up I've managed to successfully do a build, closing.


Could you take a look at bug 178383?

Note You need to log in before you can comment on or make changes to this bug.