when I run make clean from a new install of afkmud1.2b, I get the following errors....

Compiling o/i3.o....
in file include mud.h:34,
from i3.c:55:
/usr/include/bfd.h:3475: warning: declaration of 'index' shadows global declaration

In file included from i3.c:55:
mud.h:95: conflicting types for '_Bool'
/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdbool.h:41: previous declaration of '_Bool'

I also tried commenting out the i3 portion in the Makefile to try to bypass these errors, and still received them when performing the make clean.

I have not modified the code in any way.

any help at determining the problems causing these errors would be greatly appreciated.

Woo..

There was plans (and they did I believe) to introduce the bool datatype as a standard into the ANSI C++ specifications. Now I wonder if a later includes/glibc update has resulted into this spilling into the same C ref files giving us a standard bool type (which could be screwed up by the typedef and/or #defines for the bool).

Just a thought, haven't prodded RH7.3 to know yet

Well, if what Trax says is true, then the code will need to be modified. But until I get access to a system running RH 7.3, I won't be able to see how to solve that. I would have thought that any such additions to the compiler would not affect GCC 2.96, but hey. When has RH ever done anything logically? You could perhaps try compiling with GCC3 by changing the Makefile to point to that instead. But I still have no way of knowing what will come of it.

Samson,
I will more than likely be downloading and installing 7.3 on my system,
If you would like I can set you up with a shell account that will allow you to play - Please pm me if this is something that you would like.

Kilroy

DOH!

I'm being really dense sorry, must have been something to do with being at work at the time

Anyone who has RH7.3 installed take a look at stdio.h (should be in the same include dir as stdbool.h) and see if stdbool.h is included.. and also take a nose at stdbool.h and see what it does and how.. Hrm.. in fact just grep for stdbool.h in general and find out what includes it. It may help track down whats doing what.. although reading stdbool.h in the end would be best in addition.

If anyone has any probs reading them (they shouldn't be too bad) I can have a read (or Samson prolly).. unless I get ahold of the RH7.3 iso's soon and get bored and reformat my spare machine again then I'll have a read myself

I grep'd for stdbool throughout the entire includes directory and only found stdbool.h to be included in a few files....

bfd.h curses.h liba2ps.h ncurses.h

Aha.. okay so its only the bfd stuff, not the stdio or something

But this does mean where you are #include'ing bfd.h in mud.h for Alsherok it defines the "bool" symbol..

Now you could as a test comment out line 95 in mud.h and clean and compile to see what happens (I would but my machine has hung up its line for some reason and I'm on the wrong side of the line to do anything about it), theoretically that bool datatype in stdbool.h isn't that diff, and you can still stuff integers in it and perform the usual operations upon it (binary nots, ands, ors etc..)

Otherwise ppl may have to check dependancies and only #include bfd.h in the files that need it (bfd operations) or look at alternatives (like using that bool type rather than the typedef in mud.h)

In looking at stdbool.h in my Redhat 7.2 install it would seem simple enough to get around this problem by making a small alteration to mud.h as so:

Find on or near line 95:

typedef unsigned char bool;

Change to:

#ifndef _Bool
typedef unsigned char bool;
#endif

This should work, but since I don't have 7.3 handy.....

[Code removed because the board system insisted on fubaring the sample for no good reason]

I'm testing the theory of commenting out line 95 of mu.d now. So far so good, only getting warnings of the declaration 'index' shadows global decloration now. I will finish compiling the code and see what happens when it is executed. I'll also try changing the code Samson talked about as well and recomile again and try it. Will post again soon

Well, after compiling the source after commenting out ...

typedef unsigned char bool;

compiles the entire code with only the warnings of declaration of index

When attempting to execute smaug, it returns.....
illegial instruction (core dumped)

When trying Samson's idea of changing the code, when compiling, it goes back the same roblem of bool already defined.

Woodscrews..

Right the bool typedef and bool in stdbool.h are not compatible as they are.

Okay this is where I need to read stbool.h, I've seen how liba2ps.h deals with it, as it declares an enum for bool with the symbols "true" and "false" with integer values, I'm guessing stdbool.h does similar.

*IF* this is the case, you could try changing the #define for TRUE to read

#define TRUE true

and likewise for the FALSE #define (except using false of course ).

This needs the typedef for bool commented out as well so you are using the bool in stdbool.h. There should be a #define created by the system include so there will be a way to detect this and define this if its there or not (liba2ps.h talks about a HAVE_STDBOOL_H define, but I dunno where its set yet).

Still downloading ISOs (slow mirrors) so until I get a proper read I'm working on assumptions and one or two guesses here

I went ahead and commented out the affected lines where Bool was and everything compiled fine. The mud has been up and running ever since so I imagine the coredump was related to something else....

It would appear that the specific Redhat 7.3 module that causes this problem is: binutils-2.11.93.0.2-11

We just ran an upgrade on the server to this to try and resolve something else and encountered the warnings about bool stuff upon trying to compile the mud. Commenting out line 95 resolved this and the mud appears to be operating normally. So if anyone else runs into this problem, this is why. Just comment out line 95 in mud.h, which is this:

typedef unsigned char bool;

This actually intrigues me... you still using gcc3 for compiling? (Or 3.x or whatever on earth they are up to with the RH7.3 release/updates)

Yep. Just upgraded to GCC 3.1 even, which still exhibits the same issue. So it's definitely from that binutils module or later versions of it. And even though Redhat may have 3.x installed, it isn't the defalut choice, so most people will see this under 2.96RH.

Well after reading through the posts about running problems on RedHat 7.3 I still wonder if you have managed to fix it. If you have, i would be very very happy if you could let me know as I am currently starting to re-build a mud.

Thanks.

Merlin

Yes, it was fixed. At least for us. Commenting out line 95 in mud.h took care of it. This solution will only work if your binutils generates the bool type error though. So don't mess with it unless you get that error

*is planning to look at a more permenant solution involving defines... failing that hamsters..*

That would be nice, yes. Although I tried that and wasn't able to come up with something. Perhaps you'll have better luck though

Any progress on making a define? Would be nice to have for the next patch