04 Dec, 2008, Lobotomy wrote in the 22nd comment:
Interesting. So then, if you're not yet tired of having to install things, Zeno, perhaps I could give a whirl to compiling with some older versions of gcc as opposed to newer? I see that they have 4.1.2 and 3.4.6 in the packages section of the Slackware site, for instance. :thinking:
Also, I'm still curious if you were able to get the defaulting thing to work such that g++ can be set to use the older version over the newer version? I don't actually care persay about the state of g++, since I don't use it, but if it is infact possible to do that sort of thing it may be possible for you to add 4.3 without it screwing everyone on the server (in theory, anyways).
Going back to the _FORTIFY_SOURCE and __FORTIFY_LEVEL problems, apparently it's the result of some kind of bug introduced into gcc along with some sort of basic buffer overflow protection that is/was being added into to various standard header files where macros are being used to check against fortify level and source variables without first checking that they even exist (kind of a strange mistake for professionals like that to make, but I digress).
Anyhow, it seems that this protection is only enabled if you have optimization set along with a particular -D_FORTIFY_SOURCE=(#) option. This is, of course, where it gets frustrating for me. For starters, I really don't want to have optimization set whatsoever. My code relies heavily on performing exactly as it is written, and I've experienced issues in the past with things breaking as a result of trying to use optimization which seems to have the habit of rewriting things in unintended ways under the hood. For experiment sake, however, I tried compiling with optimization level 1 set and D_FORTIFY_SOURCE of 1 set. The previous compiler warnings shut up as a result, but a slew of new ones are introduced instead. Furthermore, it seems that I can't designate the optimization OR fortify flags at level 0 without causing the previous warnings to return. I'm still trying to find more information on the matter, but needless to say I'm still a little aggravated by gcc right now. One page I'm looking at for information on the matter, by the way, is here.
Addon (yay, preview):
At the part in your makefile where you have something like "CC = g++" you alter it to use the full filename of the g++ 3.etc executable. Looking at what I see from the output in the shell, the filename you want to use is "g++-gcc-3.3.6". So in your makefile, it would then look like:
Also, I'm still curious if you were able to get the defaulting thing to work such that g++ can be set to use the older version over the newer version? I don't actually care persay about the state of g++, since I don't use it, but if it is infact possible to do that sort of thing it may be possible for you to add 4.3 without it screwing everyone on the server (in theory, anyways).
Going back to the _FORTIFY_SOURCE and __FORTIFY_LEVEL problems, apparently it's the result of some kind of bug introduced into gcc along with some sort of basic buffer overflow protection that is/was being added into to various standard header files where macros are being used to check against fortify level and source variables without first checking that they even exist (kind of a strange mistake for professionals like that to make, but I digress).
Anyhow, it seems that this protection is only enabled if you have optimization set along with a particular -D_FORTIFY_SOURCE=(#) option. This is, of course, where it gets frustrating for me. For starters, I really don't want to have optimization set whatsoever. My code relies heavily on performing exactly as it is written, and I've experienced issues in the past with things breaking as a result of trying to use optimization which seems to have the habit of rewriting things in unintended ways under the hood. For experiment sake, however, I tried compiling with optimization level 1 set and D_FORTIFY_SOURCE of 1 set. The previous compiler warnings shut up as a result, but a slew of new ones are introduced instead. Furthermore, it seems that I can't designate the optimization OR fortify flags at level 0 without causing the previous warnings to return. I'm still trying to find more information on the matter, but needless to say I'm still a little aggravated by gcc right now. One page I'm looking at for information on the matter, by the way, is here.
Addon (yay, preview):
tphegley said:
so what do I put in my makefile then? Or how do I use the old version?
At the part in your makefile where you have something like "CC = g++" you alter it to use the full filename of the g++ 3.etc executable. Looking at what I see from the output in the shell, the filename you want to use is "g++-gcc-3.3.6". So in your makefile, it would then look like:
CC = g++-gcc-3.3.6
04 Dec, 2008, Zeno wrote in the 23rd comment:
Quote
Interesting. So then, if you're not yet tired of having to install things, Zeno, perhaps I could give a whirl to compiling with some older versions of gcc as opposed to newer? I see that they have 4.1.2 and 3.4.6 in the packages section of the Slackware site, for instance.
You want me to install those? They seem to be binaries, so it should be fine.
Quote
Also, I'm still curious if you were able to get the defaulting thing to work such that g++ can be set to use the older version over the newer version? I don't actually care persay about the state of g++, since I don't use it, but if it is infact possible to do that sort of thing it may be possible for you to add 4.3 without it screwing everyone on the server (in theory, anyways).
I don't even remember trying this defaulting thing..? :P Did I miss something?
04 Dec, 2008, tphegley wrote in the 24th comment:
Here is what I get when I put g++-gcc-3.3.6:
make -s smaug
Compiling o/imc.o….
g++-gcc-3.3.6: installation problem, cannot exec `cc1plus': No such file or directory
make[1]: *** [o/imc.o] Error 1
make: *** [all] Error 2
04 Dec, 2008, Zeno wrote in the 25th comment:
It's looking for cc1plus and not cc1plus-3.3.6? Uh, gimme a bit to look at this.
04 Dec, 2008, Lobotomy wrote in the 26th comment:
In a further effort to figure out a solution to the problem(s), I took a crack at installing and setting up AndLinux. Somehow, I was able to get it working on my machine and several hours later I was able to get a near-successful compile possessing none of the aforementioned errors, although there were some funky zlib-related errors I don't really understand how I would go about fixing; I may have not installed zlib correctly I suspect. The error in question is "/usr/include/zlib.h:1372:5: warning: "_FILE_OFFSET_BITS" is not defined". While I don't particularly intend to continue using AndLinux, I wouldn't mind getting some help on that particular issue if possible, as I could always use it as a backup.
Anyhow, the point is that the compilation seems to work under gcc version 4.1.3. Seeing as Slackware has 4.1.2, Zeno, I suspect that installing and/or downgrading the server's gcc to that version could fix the problems I've been having getting a clean compile on your server so far. :thinking:
Anyhow, the point is that the compilation seems to work under gcc version 4.1.3. Seeing as Slackware has 4.1.2, Zeno, I suspect that installing and/or downgrading the server's gcc to that version could fix the problems I've been having getting a clean compile on your server so far. :thinking:
04 Dec, 2008, tphegley wrote in the 27th comment:
The new afkmud doesn't compile either, but the smaugfuss new version did.
Luckily my actual game code compiles heh. Both my test codes don't (which are smaugfuss and afkmud).
Luckily my actual game code compiles heh. Both my test codes don't (which are smaugfuss and afkmud).
04 Dec, 2008, Zeno wrote in the 28th comment:
Could you post those errors with AFKMUD on Smaugmuds? You would think a recent version of gcc would be fine with AFKMUD.
04 Dec, 2008, Kayle wrote in the 29th comment:
It depends entirely on which version of AFKMud he has.
04 Dec, 2008, tphegley wrote in the 30th comment:
I have the 2.1.1 release and the 2.0 release on zeno's site. I'll put the bugs down later.
05 Dec, 2008, Lobotomy wrote in the 31st comment:
Well, while I'd still like to be able to compile under a more agreeable version of gcc, in the meantime I've found another (more intrusive) solution to the aforementioned problems with the _FORTIFY_SOURCE and __USE_FORTIFY_LEVEL warnings. It seems that they're part of the features.h header file, and thanks to information found here it's possible to force those macros to be defined at 0 (or any value you want) by doing the following:
A) Do a #define for _FORTIFY_SOURCE before all other header file includes. For Diku-deriv's, for instance, that would amount to defining it at the start of the mud.h header file. In my case, I defined this macro as 0.
B) Include the file features.h before all other header files; ideally right after the previous define. This will force all of the features.h macros to resolve themselves in the code ahead of where they'd usually be called.
C) Define __USE_FORTIFY_LEVEL after including features.h. If it's already defined and you want a specific value set to it instead, undefine it, then redefine it with the desired value. In my case, I defined it as 0.
And as a result of the above changes, coupled with using the -fgnu89-inline compiler option, the warning messages have all successfully vanished. For now, anyways. :thinking:
Edit: The above compile is the one done on Zeno's server, I meant to mention. Compiling on my version of AndLinux still doesn't work, due to the _FILE_OFFSET_BITS issue.
A) Do a #define for _FORTIFY_SOURCE before all other header file includes. For Diku-deriv's, for instance, that would amount to defining it at the start of the mud.h header file. In my case, I defined this macro as 0.
B) Include the file features.h before all other header files; ideally right after the previous define. This will force all of the features.h macros to resolve themselves in the code ahead of where they'd usually be called.
C) Define __USE_FORTIFY_LEVEL after including features.h. If it's already defined and you want a specific value set to it instead, undefine it, then redefine it with the desired value. In my case, I defined it as 0.
And as a result of the above changes, coupled with using the -fgnu89-inline compiler option, the warning messages have all successfully vanished. For now, anyways. :thinking:
Edit: The above compile is the one done on Zeno's server, I meant to mention. Compiling on my version of AndLinux still doesn't work, due to the _FILE_OFFSET_BITS issue.
Random Picks
Check out the man on how to use -V I guess. Or poke around other forums to see how it is done in Makefiles (I think Genesismuds has multiple gcc versions, so someone using it should know)