Exult Forum

Hi,

Trying to get myself back going again after my computer died, and Im on linux, so I for lack of a rpm distro for Exult, I grabbed the source, which isn't cooperating much for me.

admin@VT-Brendr: make -fMakefile.common all
make: Nothing to be done for "all"

admin@VT-Brendr: make -fMakefile.common exult.o
g++ -c -o tools/expack.o tools/expack.cc
tools/expack.cc: fatal error: U7fileman.h: No such file or directory
compilation terminated.
make: *** [tools/expack.o] Error 1

I have no such file anywheres in the source tree. Am I missing something here?

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Just to add:

Distribution is Fedora 14 (Laughlin) in case it matters. Kernel is 2.6.35.9-64.fc14.i686

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

U7fileman.h should be in trunk/files/.

If you have taken the source from the repository, it be something like this.
./autogen.sh
./configure
make (or make whatever command)
make install
If you took it from the release, ./autogen.sh likely isn't needed.

This is the source tarball from the downloads page, specifically.

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Looking at the ./files/ dir, I can see what it is; Linux file paths are case-sensitive, and the file is u7fileman.h, not U7Fileman.h

Kind of a pain, but that can be fixed.

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Hmm, a quick grep/replace didn't fix it though; looks like for some reason the make isn't parsing the /files/ dir.

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

That's really strange. Willem is on linux and he tried to build before packaging the source. Can you try grabbing the SVN directly from the repository? Just for tryings sake...
And you do the correct steps? Autogen.sh, configure, make...
Just to make sure...

Welcome back

Run 'make' (after autogen.sh and configure), not 'make -fMakefile.common all'.

I don't see any case sensitivity issues, by the way: the file is called files/U7fileman.h, and that's exactly what tools/expack.cc includes. So if you renamed any files or changed any include directives, you should change them back.

make returns that there is no makefile present, because in the fedora setup it looks specifically for "Makefile" not "Makefile.common" or for that matter anything that would pattern match, just literal "Makefile". That said I suppose I could have changed it, that was easier.

It looks like the error Im looking at is misleading, and it has to do with some SDL path variables not being present in the environment. I should think the configure script should fail if that is the case, but looking at the output it had that error and then continued. It may not be the source of the thing entirely, but its throwing a lot of errors around. I'll try reinstalling the SDL package and see if that fixes it.

-------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Okay, still having SDL problems after update to newest.

In ./configure:

./configure: line 16564: syntax error near unexpected token '$SDL_VERSION'
./configure: line 16564:'AM_PATH_SDL($SDL_VERSION,'


but I do have SDL installed:

[admin@VT-Brendr]$ rpm -q SDL
SDL-1.2.4-8.fc14.1686

So unless there's additional configuration required there? An RPM should be setting up the environment as it needs it :\

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

That should read "i686", I blame having to hand copy it from the terminal

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

make returns that there is no makefile present, because in the fedora setup it looks specifically for "Makefile" not "Makefile.common" or for that matter anything that would pattern match, just literal "Makefile". That said I suppose I could have changed it, that was easier.

Since configure fails on SDL you don't have the makefiles to do a make. You need to fix that first, you can't cheat your building beyond that.

What does "sdl-config --v" return? 1.2.4 seems an excessively old version of SDL. SDL 1.2.x branch is at 1.2.14 atm. Getting a newer one might help or building it manually might get you much further too.

Or maybe something goes wrong right away in ./autogen.sh...

That gave me:

[admin@VT-Brendr ~]$ sdl-config --version
1.2.14

Might have just forgotten a 1 when I copied from term. Really with the fedora terminal let me copy/paste from it.

It occured to me that I had not tried updating the sld-*DEVEL* packages too, and updating them seems to have flushed the problem out. Or that one anyways,

Im going to see if I cant root out the other ones. Seems like the Fedora 14 distro has some odd version descrepancies that are probably causing these errors.

If I figure everything out, I might put the RC1 into a RPM so that people don't have to go through the same trouble as I did

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

If by sdl devel package you mean sdl 1.3 this might wreak havoc since afaik sdl 1.2.x and 1.3 don't live happily at the same place...

Please report back your problems.

I mean literally the package "sdl-devel" which contains the compiler headers/etc and some tools, which allow you to build applications against the SDL library.

SDL is fine now, but it got about as far as the next line, looking for "XIPH_PATH_OGG" which again is curious. I believe that "belongs" to libogg, which I have the most recent version available from Fedora sources.
--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

If fedora distinguishes with sdl between binary and development stuff, then you probably need all other libs in devel too. Ogg, vorbis, zlib (and since you are probably interested in exult studio, all those glade, gtk, pango, cairo...)

Most distributions do.

It would be nice if somewheres in the documentation there was a list of packages that Exult needs.

---------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

I forgot to mention: I have libogg-devel-2.1.2.0-fc14.i686 but the compile error persists.

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

This all sounds like your development environment has a problem...

There is some information in the Install file (not sure how up to date that is), and some in the readme.macosx.
Exult itself requires sdl, vorbis, ogg. If you add zlib it's posdible to zip the savegames (and probably to load zipped savegames) which they are by default.
Exult Studio requires glade (2?) and thus all of glade requirements and on linux osx also x11. And thus if you compile Exult with Studio support it needs that, too.

I'm happy with documentation patches for the files mentioned at http://exult.info/faq.php#compile_snapshot

Just checked, install mentions all that is needed for exult but doesn't mention anything needed for Exult Studio.

The build environment is sane and other than software updates has not been changed from stock fedora, so really, anyone trying to play Exult on fedora is going to have precisely the same issues as I have.

sdl, libogg, libvorbis, zlib, and libglade all ship with Fedora 14. In theory the only additional installation required is the -devel branch of these files with the headers neccesary to compile. However the configure script still fails.

I really wish the first inclination wasn't to blame the component machine, but even if it IS fedora 14 to blame, like I said, since this is a pretty much stock build (only tweak being the headers install and the nVidia driver), then you're going to -as I said above - have these issues on each and every Fedora 14 install.

----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

What else have you tried to build?

Just maybe you need to set the compiler/linker flags environtments up...

The kernel and a development version of GRUB. Both compiled successfully.

--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Okay, I have built libogg from the current source, as well as the headers libogg-devel and the configure script seems to work properly, leading me to believe that the problem is present in libogg 1.2.0 but not libogg 1.2.2. This seems curious though: there were no library changes in 1.2.2 (ref: http://www.xiph.org/press/2010/libogg-1.2.2/) Its possible that the required path setting is set up at compile time pbut not package install time, which seems curious at best. I'd have to look at the relevant RPM to say for sure.

I'll have to note these version requirements for when I try to put together a RPM - if I can save future Fedora installs the trouble I've had, that'd be great

At this point, configure runs. Lets cross our fingers and see if I cant get this going.
---------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Follow-up: autogen runs, configure runs, files make properly, but the linker has issues resolving the xlib things, ie "Xfree". Now I KNOW I have those installed, or I wouldnt have a desktop working, and I went ahead and got the headers too, but it still trips up.
-----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Is this the same infamous "Xfee" the Fedorians always encounter: http://exult.info/forum/viewtopic.php?p=135523#p135523

x11 is what just about every Linux desktop is built off of, and its a temperamental beast, aye. Thanks for the link though, as Jeff, comments, one should have thought configure would add that, but evidently it does not.

Adding -lX11 to the LIBS variable does indeed fix it.
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

If someone can figure out how to make autoconf include -lX11 in libs, I can make good on my promise to package RC1 in a RPM package. I'm going to play with it myself as well, but if anyone knows, it's the one thing that's holding it back
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

So, apart from the x11 stuff you only needed to add the correct devel packages ?
If you really want to make a rpm for the oficial download, the x11 stuff is probably not needed since for a rpm you should disable ES support and OpenGL.

X11 is the windows manager. You need it to run anything in a graphical environment. So unless Im making a text-based Exult... we're going to need it (unfortunately, since apparently ubuntu and debian have had these build problems with it as well, googling around says).

I suppose I could jury rig a script to edit the file after ./autogen.sh has run but I'd rather not do "hax", if its an RPM to distribute.
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

I tend to forget that. Because I switched to Mac, x11 is just A windows manager not THE windows manager and Exult only needs it when compiled for ES. Sorry...
Figuring the problem out would be good anyway, especially why it happens mainly for Fedora...

Exult is not going to run on a Fedora system without the X11 library in its current state, and it's pointless building a RPM package, if its not going to run on a Fedora system. The linker will fail, as I mentioned above, if the x11 lib is not included. This is just building the Exult executable, not building STUDIO or TOOLS.

You are kind of right in thinking its related to ES, though: The file affected is "drag.o" which I believe is related to dragging objects from ES into Exult, however, this file is included even in the stock "Exult" main make, even if you are not building Studio. It is neccesary then to reference the window manager because you have to handle the window events for drag and drop.

My suggested fix is to only build the server framework for drag and drop if the Studio is being built. I'm not sure how feasible it is. I can understand that the current make method is to be able to make Exult and Exult Studio entirely seperate build operations independant of each other, however, it would also (in a small way) reduce the overhead of an Exult install if the user is not using the toolset.

Personally I would make the packages:
"exult-1.14.9rc1" < main no-studio package
"exult-1.14.9rc1" < package including studio-aware exult as well as ES
"exult-1.14.9rc1-src" < source package
"exult-1.14.9rc1-tools" <extra tools package (expack, etc)
"exult-1.14.9rc1-docs" < documentation package

This is in line with standard RPM conventions other than the accommodation for an ES version, since it seems to be the desire of the development team to stay away from including ES with "normal" builds.

Thoughts? This is, unlike before, something I could go ahead and figure out myself, however I don;t want to do so without some consensus from the Exult team and community. It would be counter-productive for me to start making packages and changes to accommodate the packages if it wasn't what people wanted.
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

There's a USE_EXULTSTUDIO option that includes Exult Studio specific functions. I'm not sure what, if anything is missing from that.

Ok, this diagnosing without the system did not lead to anything.
So I just tried a Fedora 14 in a VM (preconfigured with Gnome desktop) and interestingly enough Exult builds fine with the configure switch --disable-exult-studio-support. This way it didn't need the -lX11 added to the makefile.

You are kind of right in thinking its related to ES, though: The file affected is "drag.o" which I believe is related to dragging objects from ES into Exult, however, this file is included even in the stock "Exult" main make, even if you are not building Studio. It is neccesary then to reference the window manager because you have to handle the window events for drag and drop.

so in my findings, this is already done correctly in our build system. With Studio Support disabled this is not an issue.

The remaining issue is that our build system fails on Fedora to apply -lx11 to LIBS which is needed for both --enable-exult-studio-support (which is default) and --enable-exult-studio (which isn't default)

"exult-1.14.9rc1" < main no-studio package
"exult-1.14.9rc1" < package including studio-aware exult as well as ES
"exult-1.14.9rc1-src" < source package
"exult-1.14.9rc1-tools" <extra tools package (expack, etc)
"exult-1.14.9rc1-docs" < documentation package

Our version number is different.

The subpackage name precedes the version number.

The standard suffix for doc packages is 'doc'.

Source RPMS are implicit, and not really a separate package.

I'm not sure what you mean with the first two, since they both have the same name.

The Fedora 14 X11 problem is just the regular implicit DSO issue with F14. The latest Fedora linker is set to require explicit linking against all libraries used, rather than allowing implicit linking with X11 via SDL. I.e., we need to add -lX11 explicitly on X11 platforms if exult-studio support is enabled.

Yeah I was kind of halfassing the names to try to get out of my head what I meant, I noticed that after I posted too, but I cant edit posts.

Basically: "standalone version of exult" "version of exult with ES" "package for the source" "package with documentation" and "package with the extended tools". If we could fix or hack the X11 problem in such a way manual intervention isn't needed, then we'd just need "Exult" and "Exult studio" packages.

Personally I prefer to keep documentation in the main distribution, however convention seems to dictate that large documentation amount should be packaged seperately.

The Fedora X11 problem is present in the version of Ubuntu I have as well; just checked. It couldn't hurt to make builds do it explicitly.
--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Trying to get ES to compile, so that I can get back going at TFL, and ./configure complains that I don't have libglade, except ... uh, I do.

libglade-0.17.24.fc12.i686
libglade-devel-0.17.24.fc12-i686

Also checked gtk:

gtk+-1.2.10.70-fc13.i686
gtk+-devel-1.2.10.70-fc13.i686

Getting there by doing:
sh ./autogen.sh
./configure --enable-exult-studio

Specific message:
"Um, but we don't have any libglade stuff.
Try again, either with libglade, or with --disable-exult-studio"
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Configure checks for 'libglade-2.0 >= 2.0'.

Hmm, further poking seems to indicate that FC14 comes with two versions of libglade installed - or that perhaps another package installed the second version - 2.6.4 and the version listed above. Removing the older one seemed to fix it.

Starting to remember why I got off of messing with linux now
-----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Okay, Exult and ES running. Seem to connect and such, except that ES doesn't seem to load the VGA files such as shapes.vga etc, which kind of hampers item editing. Doesn't seem to be any errors associated with it looking at stdout, they just don't appear. I chown and chmodded the affected files to see if it was a permissions problem but that didn't change anything. The NPCs, combos.flex files and the pallete files load, but not shapes.vga, faces.vga or u7chunks.
------------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

There used to be a problem with the static directory being case sensitive but I thought Marzo fixed it. If it is in all caps change to all lowercase or vice versa.

Okay; I can confirm that it works in all lower case, but in any other scenario, it does not.
--------
Peter M Dodge,
aka Wizardry Dragon
www.thefeudallands.ca

I've added a bug ticket about the case sensitivity issue.

(just noting that my F14 had no problems with libglade. I added libglade devel and it worked fine on first try)

Might be a package I installed, put the lower version there in tandem with the second version. The problem with the more advanced package management Fedora uses nowadays is theres little transparency and its difficult to keep track of what has added what.

Either way it seems to be working now, other than the case sensitivity issue. Which is an easy fix, but could nonetheless probably get patched.
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

The hour I spent this afternoon with Fedora 14 didn't make me long for this system...
Getting the development environment up and running was a bit of a hit & run. I didn't have problems with the libs Exult depends on but the compiling itself was a hassle because I had to go back to the packager and install all kinds of things (gcc-c++, libtool, bison, flex..) until I got it right. Very unintuitive, I'd have expected more of an all-in-one development package (gcc (and not only the smallest part of it) and tools you'd normally need).

The case sensitivity issue is a true bug which needs squished...

Perhaps related, but maybe not: saving on new maps (IE map01, map02, etc) fails out of the box, because the engine expects /home/user/.exult/gamename/gamedat/map to exist however it does not make these directories. Creating these directories fixes it well enough, but another one of those things that could used looked at.
-----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Can you make a bug report?

Sure can do. Im curious if anyone can verify that its not just me at this point, given the difficulties I've had, though.
------------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca