I'm running g++ 4.2.3 and am not getting this error. What version of g++ are you using?

Anyhow, the fix is simple...

Zeno said:

I'm fairly certain before this fix we had warnings which did not compile due to Werror, and I recommended simply not using Werror.

Now we're getting actual errors.

Yep, and that's also one reason why I stood so firmly against removing the Werror flag since GNU has a nasty habit of making previously trivial warnings into hard errors with new releases

Let's see, this server has: gcc version 3.3.6


A habit does not guarantee they'd do that though. While it may seem like the safe thing to do, it has already created more problems. The fix may be simple, but by the time the fix gets applied who knows how many people have DLed FUSS, ran into the error and gave up when it error'd out in the first second.

It might be time to finally consider the idea of a proper dependency list.

As time marches on, it's obvious that some things change in ways that aren't always going to be backwards compatible. It's a HUGE amount of effort to maintain code using something like autoconf, but that's about the only reasonable way I know to allow code to compile on multiple environments AND multiple versions of those environments.

If we now have something which cannot compile on both gcc 3.3.x AND gcc 4.2.x, we have the choice of either using something to detect the compilation enviornment and adapt things accordingly (even if it's just toggling -Werror), or saying that as of version 1.x, SmaugFUSS is only supported on platforms with gcc 4.x or higher.

In any case, it might be good to start making that list.

The last thing I want to see happen is removing backwards compatibility.

All the while Zeno, you haven't told anyone exactly what errors are coming up. Just because there's a Werror tag doesn't mean it's broken or a bad thing. The errors may well be fixable. Or as has also happened in past GCC updates, they may be bogus and the current compilers may be making the right call in allowing the code to work.

Maintaining backward compatibility is fine right up until it holds back advancement. Microsoft hit that wall when XP came along and they're still up against it now because of Windows 98 and their insistence on keeping enough compatibility in place for apps that once ran on it. The same thing will happen here if we insist on maintaining backward compatibility with such old compilers as 2.x and 3.x.

So what would you have suggested, Zeno? Leave in all of the const problems, knowing that they have caused problems like segfaults for us in the past? The errors you are seeing are trivial to fix in the main distribution. Oops: it didn't compile perfectly on all compilers the first time around. No biggie, it's not as if it's the first time that's happened. Seriously though, it sounds like you would have left everything as is and just turned off the -Werror flag? I'm not a big fan of it myself but leaving so many warnings that are actually relatively serious is something I like even less...

All the while Zeno, you haven't told anyone exactly what errors are coming up.

I already posted the exact errors and lines in this thread on the last page.

So what would you have suggested, Zeno? Leave in all of the const problems, knowing that they have caused problems like segfaults for us in the past?

Have they? Are these const problems part of stock Smaug? Because I've been running an old version of FUSS for 5+ years now and haven't ran into this segfault issue with them.

Zeno said:

Are these const problems part of stock Smaug?

I would be astounded if they weren't.

Zeno said:

Because I've been running an old version of FUSS for 5+ years now and haven't ran into this segfault issue with them.

There was a bug report here having to do with socials causing a crash when something tried to capitalize a string literal.

Anyhow, the constness of the code was simply wrong -- why is it so bad to fix it? So the fix wasn't perfect at first; well, that's not great, but it's not the end of the world, either.

Glanced at the bugfix section, didn't see it. Do you have a link for that? Doesn't ring a bell.

Here's a bugfix related to this.

How would that be reproduced in stock? It doesn't seem that clear.

I already posted the exact errors and lines in this thread on the last page.

Remove the const before IMC_FUN. That fixes the problem.


And the fact of that matter is, that the const char* shit needed fixed, so it got fixed. Nothing's perfect the first time around, we found a slight error in the const fix. So we fix it and move on to looking for others.

At the time, the socials bug was reproduced in stock. I'm pretty sure you were the one that confirmed it in stock as well, Zeno.

Zeno said:

Let's see, this server has: gcc version 3.3.6

Just wait, the new server that SBI is sitting on has version 3.3.6 available for you (along with 3.4.6 & 4.1.3) should you decide to change your Makefile to use it (by changing your CC: line from gcc to gcc -V 3.3), but just running gcc on it will invoke version 4.2.3 (-2ubuntu7 in fact) and the 64-bit version to boot.. (the others are all 64-bit too since the new box is running the 64-bit version of Ubuntu 8.04 now.)

Oh, and the box it had been running on up until Thursday night was using version 3.3.4 (32 bit version compiled for Redhat's FC3). It's been a fun weekend so far. *sigh*

Completely random off topic tangent. But Conner, what happened to all your avatar and sig images?

His Server is currently missing a NIC, and he's been working all weekend to get the new servers set up and get everything copied over.

[Edit for grammar correction.]

Actually.. no, although you are right that it has to do with the server transition that's been driving me nuts all weekend. My server (both old and new) still has it's second NIC, but the old server's no longer running the web server daemon and the new server, which is otherwise all done (more or less) and ready to be swapped in, has developed a dislike for IPv4 all of the sudden which is making it really hard to even resolve the problem since my ISP assigns dynamic IP via IPv4 and my LAN is IPv4 based.. Dragona and I are currently working on it (even my muds and those I host have already been switched to the new box *sigh*), I'm just taking a quick forum break because the networking config stuff was making me feel the need to do so...

Oh, I thought I saw somewhere that your NIC had blown up.

You did read that on MudBytes but it was the one in my BBS machine rather than the server (which hosts my web sites, muds, and so on plus acts as my firewall and file server and... ), this weekend's efforts are just a long overdue server replacement.

Good luck on the upgrade Conner! Hardware sucks.

Warning: BOOK ahead. I guess I'm in narration mode today, sorry!


The argument of not believing a problem exists because it hasn't happened to you, personally, reminds me of an old comic argument involving cartographers.

"Why do we need to redraw all these maps? They're fine!"
"Well, no, they're all wrong. Those maps were drawn by people who believed the world was flat. We now know it's round, and so the scale of everything is off."
"Are you SURE? I've been sailing from these maps for years and always found my way around."
"Yes! You can't accurately draw a map of a sphere on a flat rectangle unless you use one of these methods that warps the lines to simulate the curve."
"I dunno. Have you checked to make sure the world is REALLY round? I trust these maps a lot more than I trust your theories!"

The fact is, compilers don't really have all THAT many bugs, per se. It's a pretty rare event for someone to find a compiler bug that produces incorrect (assembly) code, and those get jumped on pretty quick. The vast majority of patches done to compilers are to tighten up error handling and detection. gcc 4.x checks for a great many things, in terms of code usage, that gcc 3.x didn't even try to check.

It's entirely possible to have code that works perfectly for years, suddenly break with a new compiler. Sometimes that's because it now detects things you did wrong, but got away with. Sometimes, the compiler itself now handles things differently and the way you did things before doesn't work. How can you tell the difference? You can try gcc -S. That produces assembly code. If you have the old and new compilers both installed, you can have them each compile the same file and then look at the resulting assembly code.

Does it matter? Well, not really. In computers, we have two options. You can stop upgrading at a "tried and true" version, and live with the fact that you will gradually be left behind and that fewer and fewer people will be able to use what you produce, or you can keep upgrading and going back to revise your code.

I've nursed WileyMUD from it's original home on a Sun 3/60 running SunOS 3.x (Motorola 68040 CPU, SunOS was mostly BSD-derived), to a Sun 4/110 running SunOS 4.x (SPARC CPU), to a Sparc 10 running Solaris (Solaris is mostly SYSV-derived), and then to an i486 Linux 1.1.x box (Slackware), a Pentium 90 box (Redhat), a P333 box (OpenBSD!), and finally the P3-933 (Debian) box it's sitting on now.

In that 15 year journey, we've gone from the stock /bin/cc that SunOS provides, to gcc 2.x, to the stock cc from Solaris, to gcc 3.x in several environments, and to gcc-4.1.2 now. EVERY time I've had to go through and re-fix things, and almost every time I've found things that someone (maybe me, maybe the Diku authors, maybe one of the other devs from years ago) did that was clearly wrong, but that the older compiler let slide.

I think people who are already here, and already use Smaug, will be able to adapt to changes as they come along. I don't want to abandon folks on older systems either, but I also don't want to see things stall out because too much energy is being devoted to keeping things running on the older systems.

It might be as simple as putting some comments in the Makefile on ways to get things running with older compilers. "If you're using gcc 3.x, disable these warnings. If you're in FreeBSD, do this. In ALL cases, be aware that things might be broken if you do this."