#14 SDL_gfx SRPM doesn't build on virgin CentOS 6 box

[Warren Young]

I have run into two problems trying to build an RPM from the source tarball per the README-rpm instructions on a freshly-installed CentOS 6.4 i686 box.

The first one I diagnosed and worked around: In the "cd Test ; make" step in the spec file, at least one of the programs in Test does a #include SDL/SDL_gfxPrimitives.h, which fails because there is no "SDL" directory in the include path at that point. I had to install SDL_gfx from the source tarball build so that there would be an SDL/SDL_gfxPrimitives.h in /usr/local/include for it to find.

In other words, the SDL_gfx RPM cannot bootstrap itself. It depends on having an existing installation in a default location.

The second I've simply run out of time trying to fix. This command:

install -m755 -d /root/rpmbuild/BUILDROOT/SDL_gfx-2.0.25-1.i386/usr/share/SDL_gfx-demos

results in a huge "cp" command (20 or so lines) that fails because apparently there is no Test/m4 directory. I don't know why that is the case, and haven't got time right now to figure it out.

[ferzkopp]

Thanks for the bug report. I am not an RPM expert (the spec file is quite old) - any suggestions for a fix (i.e. a patch file) would be welcome.

Some things I could think of:
Issue 1 may be solvable by adding the local folder (..) to the set of include paths for the spec build.
Issue 2 may be solvable by adding an ./autogen.sh in Test to the build sequence (which would populate the m4 folder via libtoolize).

[Warren Young]

Re issue 1: See line 74 in the spec file, then re-read my report.

I offer several possible fixes:

1. Make the #includes in Test/*.c conditional:

   #ifdef SDL_GFX_BURIED
   #  include "SDL/SDL_gfxPrimitives.h"
   #else
   #  include "SDL_gfxPrimitives.h"
   #endif
   

   (You've already got something like this going with Win32. Win32 isn't the only platform where this is a good idea, though.)

2. Use explicit paths in the includes for SDL_gfx files, going with the assumption that you always build the test programs against the in-tree files, not any preinstalled ones:

   #include "../SDL_gfxPrimitives.h"
   

3. cd Test ; ln -s .. SDL

   This won't work on Windows, though, and it's ugly besides.

Regardless of the option you choose, remove -I../ from the spec file, since it probably isn't doing anything useful.

Re issue 2: In that case, the tarball isn't built correctly. End users should never have to run the autotools on their systems. The files packed with the tarball should suffice.

Old tarballs sometimes don't build on newer systems because the old config.guess or configure script doesn't understand some aspect of the new system. Re-generating these files can fix build problems, since you're using Autotools compatible with the newer system to do the rebuild. This exception doesn't apply to maintained software like SDL_gfx.

Bottom line, the tarball needs to have a populated m4 directory.

I tried it anyway, and all it does is get the process just one step further down the road. Now it complains because the cp command a few lines down in the spec file effectively makes it try copying directories without -r:

cp: omitting directory `Test/automate.cache'
cp: omitting directory `Test/m4'

I doubt adding -r is the right solution here.

I replaced the command instead:

find Test -maxdepth 1 -type f -exec cp {} ....etc...

Now the RPM builds. I haven't yet tested it to find out if the resulting RPM is actually useful. :)

[ferzkopp]

Fixed with r100