Freeciv
Don't have an account?
Register
Advertisement
Register

SDL build

Phlox
Phlox • 15 September 2012 • User blog:Phlox

Using the previous MinGW/MSYS environment that I have been using for GTK2.0 client builds, I took the following steps

  • attempt to config using ./autogen.sh --enable-client=sdl --with-libiconv-prefix=/usr
  • dies with checking for SDL-version = 1.1.4... no
  • Download SDL 1.2.15 libraries
    • SDL-devel-1.2.15-mingw32.tar.gz (Mingw32) from this page - see development libraries section.
  • copied to home/sdl1_2, typed make native. This copied stuff to local\include and lib.
  • re-autogen, dies with IMG_Load in -ISDL_image...no
  • download http://www.libsdl.org/projects/SDL_image/ SDL_image-devel-1.2.12-VC.zip. VC notation is alarming, but there is no mingw ver.
  • zip has just inc and lib. copied stuff to local\include and lib.
  • autogen dies same place
  • This forum post describes problems installing on ubuntu...
    • "You need -dev packet for SDL-image too. That's four packages related to SDL: libsdl1.2, libsdl1.2-dev, libsdl-image1.2, libsdl-image1.2-dev." --Cazfi
    • questioner states: "problem solved.. The make file was looking for SDL_Image.h in usr/local/include/sdl"
  • Ok, so I copied the SDL image files to minGW\msys\1.0\local\ include and lib... there is now a local/include/sdl directory.
  • No dice
  • Ok, copy sources to home\sdl_image, configure, make
  • busted on png lib. are we having fricking fun yet. THis is so stupid.
  • Ok download lpng source (got latest-1.5.12 from sourceforge), autogen.sh, configure, make, make install ok now we have built fricking lpng
  • Go back to sdl image and make... still can't fricking find lpng. Ok search for it. find libpng1512 etc type names and also- lots are dlls, whatever... I see SDL_image.lib not in local\lib. hmmm copy that one to local and see if autogen of freeciv-sdl works
  • nope
  • Huh. Shouldn't be this tough, maybe I'm doing something way way wrong. Googled mingw msys sdl and found this "SDL is great and it lives here. But if you're not already a guru, it can be difficult to install, and there aren't many if any step-by-step instructions for getting it working..."
  • SWELL.
  • Ok, back to square one, searched the fc23 directory for the error message, found it in fc23\configure. followed the variable back and am led back to SDL_CONFIG=$sdl_exec_prefix/bin/sdl-config. never seen an sdl-config directory.
  • sdl-config.exe is in the \usr\bin directory and spits out a bunch of stuff about where libs, what the cflags are, what the exe root is. /usr ??? so SDL_CONFIG is \usr\bin\sdl-config
  • It thinks \mingw\include and lib are the correct locations. Ok fine, move sdl_image and the other libs and .h there
  • Nope
  • Pathetic.
  • Unbelievable. This tutorial, linked to from the SDL site is the instructions for installing sdl on MinGW/MSys platform. I was right above. THey really really do want you to fricking build the whole bloody thing. (including the various image libs). Boy, they must really really not want anyone to get their feet wet with SDL.

Let's have a little more pain[]

  • ok, looking not sure why CONFIGURE test prog (with an IMG_LOAD attempts link with SDL, rather than SDL_image.lib. Whatever.
  • nm on SDL_image.lib shows it has an IMG_Load function, so I don't get what is so fricking hard to find about this link data. If this were not a gnu compatible lib, then nm wouldn't read it, right? So wtf- it is a correct lib, but it won't link the IMG_load call.. This is so painfully trivial thing and it won't work. I am getting real real pissed off about this gnu build bs. This has got to be about my lack of familiarity, but I am seeing lots and lots of complaints on the web about this same obscure arcanery that is only solved by some kind soul leading the novice through. Novices should not need veterans just to do a simple hello world test program. This is too brain damanged. No wonder open source is going nowhere. These guys have made it into an arcane cult.
  • Wow. Others are hung up in the same SDL_Image build arcanery I am. It has to do with the excessive manpower necessary to create and test configurations for variations of platforms that may not interest the individuals who have sufficient knowledge to create them. They have other fish to fry and the thought of fixing up a Mac or Windoze configuration which requires setting up test machines with typical tools is about as pleasant as getting a root canal.
  • Of course the obvious approach is simply to adopt the tools and environment that the authors of a particular piece of open source code used. That's a high barrier to entry for novices, but it is practical in some senses because there is far less bandwidth chasing down bugs due to ridiculously arcane platform dependent tool variations.
  • Trudge on. Configure sdl-image. Dies on SDL not found. Wtf. back to SDL, make install that
  • still SDL_image says SDL not found. Beautiful. You do the out of the box setup for a major package, and another major package doesn't recognize how it configured the puppy. You know, I do have some real work I'd like to get to and it has been almost 3 weeks of this nightmare of these obscure obstacles....
  • Ok. Back to libsdl. Read MinGW instructions again. Says I should extract SDL and make... woops this says there should be a .config and mine doesn't have that. I downloaded the SDL-devel-1.2.15-mingw32.tar.gz. Oh genius. Maybe Mingw32 is not what I want though it sure looks like it. Well whatever ok try the pure source package. No short cuts just do whatever these instructions say.
  • Ok, download SDL-1.2.15.zip from http://www.libsdl.org/download-1.2.php into a build directory. config is grinding away... ok bueno, doing make now. Jeez this thing has the kitchen sink in it. I wonder if the gnu linker is smart enough to optimize out dead code an exe isn't calling. Probably have to do it by hand. Anyway, that is optimization tuning. That's one nice thing about having to build the universe before you can write a hello world app. Ok great the thing is done. make install and NOW config sdl-image should be happy. Right? sdl-config --libs now gives reasonable locations.
  • ok sdl_image and configure. Cross fingers ... Hmmm got through but it is unhappy about no tiff, jpeg or webp libs. Apparently found png though.
  • huh. It got through make without Tiff and JPeG?!? whoa well this probably needs to be rebuilt with them or I may have some weird behavior. But as I recall the freeciv guys are using tranparent pngs so maybe this lean sdl lib will suit them.
  • ok I am skeptical this will work but try try again. ./autogen.sh --enable-client=sdl --with-libiconv-prefix=/usr
  • well son of a gun. FC is ready to make. I would go out for a smoke to celebrate except I quit 25 years ago.

FC2.3 gui-sdl build[]

Above, we got through the config hell for sdl. At this point we have a configuration that fc's autogen has given the thumbs up on. (Using ./autogen.sh --enable-client=sdl --with-libiconv-prefix=/usr). We rejoin our hapless protagonist attempting to do a make in the FC 2.3 root directory

  • Passed the gui-sdl step, right out of the box. But dieing on link in client:
make[3]: Leaving directory `/home/fc23/client/gui-sdl'  YAY!
....
make[3]: Entering directory `/home/fc23/client'
 CCLD   libfcgui-sdl.la
 CCLD   freeciv-sdl.exe
C:/MinGW/msys/1.0/local/lib/libSDLmain.a(SDL_win32_main.o): In function `console_main':
C:\MinGW\msys\1.0\home\sdl1_2/./src/main/win32/SDL_win32_main.c:315: undefined reference to `SDL_main'
  • Well that's pretty basic. Wonder wtf... K. will look.
  • Ok, gui-sdl\gui_main.c main() comment says " SDL has macro magic to turn this in to function named SDL_main()" Huh. Apparently this is Aunt Clara magic because something goofed. "macro magic". WTF is that supposed to mean. more arcanery. okey dokey at least we have the internet these days. let's see.
  • Ok I get it. SDL wants to slip to the head of the line and this is C so they can't override so they just hack it by trying to rename our main(). Really hackish way of doing this but whatever. Ok so I get their intent. Now where is the dang magic macro. Probably in SDL.h somewhere.... lessee. Ok, it's in sdl_main.h, but I don't get how this is supposed to alias the link symbol, nor do I get why gui-sdl doesn't just export it as SDL_main rather than main(). oh..... it would be just swell if this "magic" is creating a dependence on order of includes.
  • humph- the signature is right, argv is a **char.... humph. if I change it, the gui-sdl link even mentions SDL_main, so the macro has introduced the symbol ok. Why is libfcgui-sdl being used as an intermediate... Oh yeah, that cockamamie idea of having a dummy.c program as a hack to get around some automake build problem they were having with circular dependencies or something like that. Anyay, nm shows SDL_main in the .a file so its there... Link just isn't connecting them. If I lift the SDL_main and put it in dummy.c? No problem with the link. Totally bizarre. It's a static lib and the linker says the default is export all symbols and nm shows it anyway. The signature is right otherwise the dummy.o would not link either. It's that weird aliasing they are doing. Some arcane hack the maybe worked with an old version of gnu tools but no longer does. You can redefine with a def file or ifdef the SDL_main name. Don't see why they had to go to all this ridiculous effort with this "magic" macro that breaks so easily and is such a PITA to figure out what and why they are doing this nonsense. Really, I don't see why this had to be made so fricking complicated. SDL wants a different named entry point from main. SO ifdef the function name and the prototype. Its all there clearly in one place in the C code. No fragility everything plain as day. End of story.

Epilogue[]

It turns out some kind soul fixed this situation in 1.24. Unless 1.24 changes are highly suspect, I am not inclined to continue the investigation why the configuration failed on the freecivclient-sdl.exe link. If it worked before, I don't see any good reason the gnu tools are not allowing it now. I even tried forcing export of the SDL_main with an XLINKER --exportsall on the cockamamie intermediate .la they are building. No dice. But it's not clear to me why this so called "macro magic" would work- Aliasing is done all the time, so why not stick to the tried and true ways of doing it? To prove what a hot shot you are about undocumented compiler behavior that will break with the next compiler release? That's not helping the greater cause. Anyway, an explicit extern from the .obj works, so I will leave it in that hackish state in my tree until I form an opinion about where the main code base is going.

There is a ton of unappreciated stuff in the FreeCiv code base, but it seems to me that the configuration scripts have been neglected. I understand how it can happen. You get your makes the way you like them and never really go back and bother with the configs until it is time for a development release. I'd like to believe that the installs are fairly smooth on linux platforms, but I see complaints on those too. As far as I'm concerned, if we don't have at least one configuration and set of instructions that will work for every major platform, then we are turning away potential code collaborators.

As of now, I can build gtk and sdl in minGW and debug them in VStudio. When I get some spare time will get around to set up a linux box most like whichever one the preponderance of current contributors are using so I can test changes cross platform.

Community content is available under CC-BY-SA unless otherwise noted.
Advertisement