Symbol References: __gxx_personality_v0 [GCC3 Requirement]

[segv]

I am writing to inquire if there is a true need for the GCC 3.0 requirement: I have compiled ShowEQ 4.0 under FreeBSD with gcc 2.95.2, and the only indication of this requirement is that libEQ itself is compiled with GCC3.

/usr/local/lib/libEQ.a(libEQ.o)(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
gmake: *** [showeq] Error 1

This reference appears to be part of the exception handling routines in GCC 3.0. Any chance of getting a libEQ compiled with a more stable GCC release?

[segv]

I wanted to also note, that I intend on completing a Solaris port of ShowEQ. Since GCC 3 is not yet stable on SPARC architectures, it would again be nice to get a lib compiled 2.95.x. (Nor is GCC 3 in the FreeBSD-Stable branch)

[Yendor]

Got further than me, when I tried to force it to use 2.91 it barfed all over the place while compiling so I assumed there was a real need for 3.x (I didn't investigate it closely). But I was using a real old install, so who knows where the incompatibility was. Interesting...

[malakin]

I got it to compile using gcc 2.96-0.62mdk but I had to use the a38* libEQ.a since I ended up with the gxx_personality_v0 problem also. I tried matching up the opcodes with what a38* was expecting and it didn't work although I only tried it once and never bothered to debug it any further, no time with all this christmas stuff. If anyone gets this working please post it here, I really don't want to have to installl gcc 3 just to check out what's happening with seq (i'm a sins user).

I also had to remove the libEQ.a detection code and manually add the define since it wasn't finding it for some reason.

[Elberg]

I just want to point out a few things here that are (apparently) being overlooked.

From what I can tell, GCC 3.x is a requirement for the sole reason that libEQ.a is being built by someone who is using GCC 3.0.2.
Attempting to use GCC 2.96 (the screwed up version that RedHat decided to use in one of the distributions) will never be "safe" to use, no matter how many hacks you add to the build scripts because 2.96 makes binaries that are not compatible (to greater or lesser degrees depending) with binaries produced by *any* other version of GCC. The GCC Devel team has spoken at length on this in the past.

The *latest* released version of GCC is 3.0.3. This is important because of the version of glibc you may or may not be using. If you are using glibc 2.2.4 (which is the latest and recommended version) then you will NOT want to be using it with anything less than GCC 3.0.3. There were dire warnings from the GCC developers about interactions between glibc 2.2.4 and 3.0.1 and possibly 3.0.2 as well--I'm still digging, the notice I mention was pretty obscure. Glibc-2.2.4 would not build and pass self-tests using GCC-3.0.1 for good reason, and these issues may not have been fixed yet. i.e., be prepared for weird problems to creep up with other things you build if you do this, because GCC 3.0.x is still pretty darn new and the GCC Devel team will likely tell you the same thing.

So, if you intend to upgrade your GCC I strongly recommend proceeding with caution unless you are a complete RPM monkey with no skills for being able to manipulate binary tools, in which case it's out of your hands in the first place. You will very likely need to upgrade your glibc to 2.2.4, and you will never, ever get it to pass it's self tests unless you're using a 2.4.x kernel as well (just to prevent further questions along this same vein).

Tip to developers: Next time you wanna make a compiler tool jump like this, think twice unless you have a burning need for a feature found in the newer compiler. If this was supposed to reduce the number of people using the program, it's effectiveness in this is limited at best. For the RPM monkey RedHat users that frequently post plaintive cries for help, it's a complex mess to upgrade with RPMS, but can be done in under 20 minutes. For people like myself who actually know how to build things properly (I know the difference between semi-colons and ampersands. Heh) and actually have the ablility to find bugs and make patches, making this upgrade is about 12-36 hours of compiling and regression testing minimum.

I'm not saying the change shouldn't have been made... I'm saying that I suspect not enough forethought went into making that change to the new requirements.

[Ratt]

Updating your system to handle GCC 3.0.x does not take anywhere near 12+ hours for an experienced person.

Given compile times on an average system (PIII 500 say) takes 3 - 4 hours at best.

I know there's a lot of angst about upgrading, but catering to the lowest common denominator is one of the biggest failings of a lot of software out there today. I know that there is a need for backwards compatiblity in some cases, and it makes good business financial sense, however, we are not encumbered by such stipulations on the software.

Yea, it's a pain in the ass, but suck it up and drive on... get the upgrades done and you'll be fine.

[segv]

Still, I remain curious as to whether or not there is a real motivator for the new compiler requirement. As I mentioned earlier, it would seem the only requirement for GCC 3.X is due to the fact that it is being used to compile libEQ itself.

Are there compiler enhancements in 3.X you intend on taking advantage of? Or is this merely for the convenience of the core development team?

There are those of us who haver rather complicated development environments. Upgrading to a new compiler version, especially an unstable one, can have impacts well beyond the scope of this project (including actual system stability).

If need be, I will volunteer to test and debug showeq with older compilers for backward compatibility, as well as compatability with other unices. I simply need a libEQ compiled with 2.95.x. (Indeed, it is already my intention to maintain showeq for FreeBSD, since I do this already for myself).

[Elberg]

Pfft. It very much does take that amount of time and then some...

An *experienced* person would know that changing the compiler (when it affects shared libraries in such a fashion as to make them incompatible with previous versions of the compiler) requires at least considering a recompilation of the _other_ things on the system that link to shared libraries, and this would most certainly include glibc... and if you're compiling and installing a new glibc without running it's own self-tests, well... there's no way to say it other than "that person is a moron". A major revision change of one's compiler is *not* something to be taken lightly. Heck, it's going to take me at least three hours just to go through the gcc-devel archives to make certain the rather specific problems that existed previously between gcc and glibc-2.2.4 have been ironed out for gcc 3.0.3.

[Elberg]

segv: I'll go ahead and say that IMHO you're right about that... From what I've been able to dig up so far, there's some improved optimizations in the 3.x comiler and some improvements in the way the g++ frontend handles overflow incidents, but nothing that would make code particularly incompatible to compile with gcc-2.95.3.

So that no one gets the idea that I'm all about vitrol and condescension or something I will say that the 4.x code looks considerably cleaner and I'm being told it's faster than the old code, but I'll hold off on my final judgment until I've had time to check it for any more insane uses of case statements. ;)

Oh, and before anyone suggests this, gcc-3.0.3 compiles fine for cygwin, so this won't stop the windows lamers from linking the libEQ.a to their "port" of ShowEQ. Very possibly some strong language about not linking with Windows apps should be added to the licence used for future binary-only releases of the library... They might or might not decide to abide by that, but at least there would be a more concrete reason to bitch at those people for screwing things up.

I, for example, think the game is boring enough without taking all the mystery out of when the next train will arrive, but I know for a fact that tons of people use the thing to cherry-pick, outright cheat, and worse, so I'm all for raising the barrier to entry. Pretty much the only thing I've ever used it for was to make maps and document where all the NPCs are in a hurry. ShadowHaven, Sanctus Seru, and Katta would have taken several hours each to census without being able to dump the spawn list and feed it to some perl scripts to make an annotated map, and frankly, anything that causes Verant to make changes to an already sketchy codebase (like, say, a few thousand windows users using it with EQW to cherry-pick all the rare spawns) is bad, bad, bad.

[segv]

How about that GCC 2.95.X compiled lib?

GCC 3.X = Brokedick Compiler