Problems building core-2.8

[eeriegeek]

In my ongoing saga of trying to upgrade my dev computer to fedora 16 I checked out the core-2.8 branch from git to build. I ran into a number of problems shown below. Some of these problems may be due to trying to use the bleeding edge release but any help is appreciated.

*******************************
#1
The install.sh script checks `uname -p`. I'm building in a full i386 chroot environment on x86_64 but `uname -p` reports the host architecture, not the the build environment. Something like `gcc -dumpmachine` might be a friendlier test. I ended up just building with individual commands.

[elven]

Hi,

regarding building core-2.8: I migrated core-2.8 to cmake, which does proper dependency handling (as opposed to the broken configure script we had). It should build fine with that without any env twiddling, given libmysqlclient is installed. I have also tweaked some of the build flags so that that warning will not make gcc bail anymore. Proper patches to address those issues will follow.

The mysql-rename-problem is known, and the easiest fix would have been to rename the binary of your choice to nwnx_odbc.so, as recommended in the downloadable builds. This will also receive a patch.

I have (just now) updated the git mirror on GH to reflect this. If you were kind enough to retry with a new checkout from git or svn, I'd be much obliged.

Alternatively, if you don't want to build yourself, you can also give the binaries produced by CI a shot.

Thanks for reporting the uname -p issue: it works on chroots running on Debian/Ubuntu. Not sure what's the difference on your environ.

[eeriegeek]

Wow, thanks for the update and fast reply elven! I'll be trying all this out today and let you know how it goes.

[eeriegeek]

Hey, an update on my fedora core 16 build attempt.. now using the new cmake check-in to build.

#4
The build fail on warning message in the spells plugin is gone. No problem there.

#5
Renaming the library nwnx_odmbc_mysql_dynamic.so to nwnx_odbc.so (or creating the symlink) works like a charm.

I finally tracked down the dload errors:

[elven]

I installed FC16 in a VM, and have reproduced the described problem. Good catch on that inline bug! I will see what can be done about that.

Also, MySQL (among others) won't compile, because /usr/lib/mysql isn't on the global search path for FC16. I will patch that into CMakeLists I guess.

btw, here is the background on the rename problem.

[eeriegeek]

I think picking up the module name from the filename is actually quite elegant! I just missed that along the way in my build process. The only thing I would add is a clear note, maybe in the install script's post-install message to remind the installer to do it.

Before you go to crazy on the db cmake.. I lernt a little cmake yesterday and came up with this basically re-written CMakeList.txt for the odmbc directory that uses the default FindPostgreSQL cmake module target and two others I found on the internet for SQLite3 and MySQL.

[eeriegeek]

I'll just post the cmake database finder modules here since they aren't that long and somebody else my find them useful. I put them in a directory named CMakeModules at the project root.

FindMySQL.cmake

[elven]

[elven]

I've committed your changes to my integration branch. I had to get FindPostgreSQL.cmake from Ubuntu, since the debian squeeze version can't find it's own installation. Ohwell. They will go into svn eventually ..

Also, mysql static builds are once again removed, since it breaks on Fedora.

[eeriegeek]

Just as a quick summery, I think that all of my points above have been resolved or have solutions in the works except #7. I continue to get server crashes in RetrieveCampaignObject. This was happening in my core-2.8 Fedora Core 16 i386 chroot build. Since then I have set up a Fedora Core 14 i386 xen vm. The crash is happening in both my own build of core-2.8 and elven's latest integration build (static mysql). The stack traces are identical from both versions, and very similar to the Fedora Core 16 version.

[eeriegeek]

Ok, I figured out what seems to be going on. It looks like in the move to cmake in core-2.8, the compiler flags from the make files have been lost/changed and some things were not at all happy about it. The most important seem to be -mtune=i386 -m32 and -fPIC. Without the i386 architecture flags, gcc generates alternate stack frame handling which does not play well with the hooks procedures like RCOproc in particular, causing memory corruption which was generally showing up as a random error in memory management a few moments later.

[elven]

That's a very good find. I haven't yet verified it myself, but I still took the liberty of incorporating your fix. Reasoning seems sound and the resulting code works.

Thanks for your detective work ..