Make file and C/C++ changes

Posted by Greven on Thu 15 Jul 2004 06:41 AM — 3 posts, 10,866 views.

Greven Canada Thu 15 Jul 2004 06:41 AM #0

K, two questions for people:

1. Can make files me used to detect what operating system is being used? I'm thinking of auto-detecting so that you can have differy\t flags used for say Linux and another set for Cygwin. If this can't be done, I see a couple post in the DoT section about a configure file to do something similiar? Could this be adapted? I'm uncertain as to how this works.

2. I've been compiling for some time with gcc, though my code used to work properly in g++. I don't get any compile warnings, but during the linking with g++ I get this:

Quote:
o/channels.o(.text+0xfb8): In function `do_showchannels':
/home/mud/darkwars/dwadmins/src/channels.c:508: undefined reference to `pc_displays'
o/channels.o(.text+0x141a): In function `do_setchannel':
/home/mud/darkwars/dwadmins/src/channels.c:642: undefined reference to `pc_displays'

Where I do not get it with gcc. I know that c++ handles const pointers differently.

I have this declared in my channels.h, which is included in channels.c

extern char *const pc_displays[MAX_COLORS];

The array in defined in color.c as such:

char *const pc_displays[MAX_COLORS] = { /* etc */ };

Dunno what the deal is with this, and I can't seem to find any specific reference to this issue in a couple c++ books I got. Any ideas?

Nick Gammon Australia Forum Administrator Thu 15 Jul 2004 07:08 AM #1

I'm not sure about the makefile, you are also thinking of autoconf, which produces configure scripts. A lot of software uses that to produce a config.h file which is then included into the other files to produce system-dependant defines (eg. compiler-dependant, endian-ness and so on).

As for the channels.c, that doesn't seem to be in standard SMAUG, but I vaguely remember there is some strange problem with extern const. You could try taking the const off.

Here is a page that might help:

http://www-h.eng.cam.ac.uk/help/tpl/languages/C++/Thinking_in_C++/tic0091.html

This bit seems relevant:

Quote:

The C++ compiler avoids creating storage for a const, but instead holds the definition in its symbol table, although the above extern forces storage to be allocated, as do certain other cases, such as taking the address of a const. When the const is used, it is folded in at compile time.

Of course, this goal of never allocating storage for a const cannot always be achieved, especially with complicated structures. In these cases, the compiler creates storage, which prevents constant folding. This is why const must default to internal linkage, that is, linkage only within that particular translation unit; otherwise, linker errors would occur with complicated consts because they allocate storage in multiple CPP files. The linker sees the same definition in multiple object files, and complains. However, a const defaults to internal linkage, so the linker doesn’t try to link those definitions across translation units, and there are no collisions. With built-in types, which are used in the majority of cases involving constant expressions, the compiler can always perform constant folding.

It seems to be saying that a const expression (like, your array) is not saved as part of the .o file, and thus cannot be found by the linker. However when compiling the actual file in which it appears the compiler substitutes the const values where appropriate. Hard to see how that would work for an array, but there you are.

Greven Canada Thu 15 Jul 2004 07:38 AM #2

Yeah, its a culmination or my custon OLC channel code and of Samson's new color parsing code.

Indeed, that page was quite helpful, thank you. I guess keeping const definitions to internal linkage makes sense, kind of wierd thing to come across. I didn't see anything happen with any of the other const pointers arrays, but hey, I got it to work.

Should anyone need to know, I just added the bold line above the definition for the array:

extern char     *const pc_displays[MAX_COLORS];

char     *const pc_displays[MAX_COLORS] = {

This doesn't complain in g++ or gcc, so I guess its pretty safe.