18 Jul, 2009, Theodryck wrote in the 21st comment:
Votes: 0
Compiles fine. 0 warnings or errors on a clean/full compile. And I know what str_dup and strdup are. I personally don't have anything against glibc as it relates to linux. But it's not even really needed for mud code and with all the new header files and library changes it makes it tough to sift through. You yourself have been know to say so about glibc yourself, Samson. And glibc *does* give mud developers fits on a daily basis. It's open source and bound to have compatibility problems here and there. That's the nature of the beast.

I'm not blaming gcc4 or glibc for my problems as they are needed updates in the evolution of linux. But I do blame them as they relate to my mud because mud code is from the stone age as far as computers go. Still valgrind itself points to outside header files and not mud files as the source of my problems.

We can toss this stuff back and forth all day but in the end I'm still stuck looking at my screen with valgrind telling me unitialized variables from ctypes.h or bits.h and etc. Those are included files with the gcc4 package. Not a lot I can do about that except try to track them down.
18 Jul, 2009, Guest wrote in the 22nd comment:
Votes: 0
Theodryck said:
You yourself have been know to say so about glibc yourself, Samson. And glibc *does* give mud developers fits on a daily basis. It's open source and bound to have compatibility problems here and there.


I think perhaps you're confused as to which is which. glibc are the core system libraries. I've never complained about those, because none of the changes made to them have ever affected anything I do.

I have regularly complained about gcc/g++ and the GNU gang's incessant need to change the compiler at the drop of a hat causing untold grief as the world now needs to obey their newly imposed dictates. I don't think it's serving anyone to have them constantly making code breaking changes to that.

If valgrind is telling you there are uninitialized variables in your system libraries, something is wrong. It shouldn't be doing that. I've used valgrind a lot, and I've never once seen it complain about the system headers. Except in zlib, but I tossed in a suppression for that library. Maybe if you'd post some of what valgrind is telling you we could see what the real deal is?
19 Jul, 2009, David Haley wrote in the 23rd comment:
Votes: 0
Theodryck said:
Still valgrind itself points to outside header files and not mud files as the source of my problems.

That could still be problems in your code: if you pass uninitialized variables to stdlib functions, the stdlib function will be where they're used, hmm…?

Let's put it this way: it is very unlikely that your crashes are caused by bugs in glibc. It is far more likely that your code is not using them correctly one way or another. If the stdlib was as buggy as you seem to think it is, well, let's just say that people would have noticed.

As Samson said, the best thing to do at this point is to show us examples of problems you're seeing.
19 Jul, 2009, elanthis wrote in the 24th comment:
Votes: 0
Theodryck said:
I personally don't have anything against glibc as it relates to linux. But it's not even really needed for mud code and with all the new header files and library changes it makes it tough to sift through.


You, sir, have no idea what you're talking about.

Without libc, your MUD does not run. It cannot open sockets, it cannot send data to sockets, it cannot allocate memory, it cannot read files, it cannot do anything. Unless you're implying that you want to manually write the assembly code to invoke Linux syscalls instead of using the POSIX API, your MUD absolutely 100% definitely needs libc.

Quote
And glibc *does* give mud developers fits on a daily basis.


No. Poorly written MUD code gives MUD developers fits on a daily basis. If the code was written correctly in the first place, it would compile and run without problems on glibc or any other POSIX-compliant libc.

Quote
It's open source and bound to have compatibility problems here and there. That's the nature of the beast.


No. The fact that it's Open Source is irrelevant. The fact that glibc has been backwards compatible with Linux binaries and sources written over 15 years ago is relevant, and is more evidence that it's your code (or the code you inherited with the codebase) that is at fault.

Quote
Still valgrind itself points to outside header files and not mud files as the source of my problems.


Then either you installed your system incorrectly (you did do the sane thing and just used the distro RPMs for GCC and such, right?) or you're using them wrong. Garbage in, garbage out.

If the headers you're compiling against do not match the glibc binary you're linking against, it is possible to get some weird errors. When glibc does break ABI compatibility (long file support, for example), they use some tricks to ensure that old binaries keep working. This revolves around using versioned symbols and preprocessor and linker tricks to compile/link against the correct symbols. If your headers are for a newer version of glibc than you're linking against, it may be trying to link in improper ways.

Quote
We can toss this stuff back and forth all day but in the end I'm still stuck looking at my screen with valgrind telling me unitialized variables from ctypes.h or bits.h and etc. Those are included files with the gcc4 package. Not a lot I can do about that except try to track them down.


Can you actually post the Valgrind errors?

Also, is Valgrind installed by packages or by source? There are known "errors" in the libc headers (which aren't really errors, but Valgrind whines about them) that a proper Valgrind install is configured to ignore. If those are being shown for some reason – possibly a bad install – then you are chasing a red herring.
19 Jul, 2009, Runter wrote in the 25th comment:
Votes: 0
elanthis said:
You, sir, have no idea what you're talking about.


You must forgive Elanthis. He's cantankerous.
19 Jul, 2009, Tyche wrote in the 26th comment:
Votes: 0
I'd recommend formatting your drive and installing Windows XP or Vista, and the Visual C++ Express Edition.
That should fix all your Linux/glibc problems.
20 Jul, 2009, elanthis wrote in the 27th comment:
Votes: 0
Quote
You must forgive Elanthis. He's cantankerous.


Yeah, sorry. I went to the clinic and got a cream for it, should be all cleared up in about a week.
20 Jul, 2009, David Haley wrote in the 28th comment:
Votes: 0
Elanthis may be cantankerous :wink: but he's also correct, and in some sense it is more helpful to explain why somebody is all wrong, rather than just telling them that they're wrong and leaving it at that.
20.0/28