I'm having fun monkeying[0] with linker scripts. This is the kind of thing that makes console programming a total pain in the butt. We're using a 3rd party linker (SN Systems) with gcc (2.95 series[1]) and everything had been working fine until I had to add in libraries from the publisher. This produced lots of complaints from the linker about the global pointer. After searching through documentation and trying to rationally analyze the problem I did a diff between some linker scripts and cut & pasted a chunk of the old one into the new one. It works. Now I just have to wait for an "I have no idea what I'm doing" change to bite me in the ass.
[0] Monkeying, because I can't find the documentation and I haven't done this before. When things go right I only have a vague hypothesis on why they went right.
[1] Yes, we should probably rev this, especially as we are using templates in our codebase and the gcc 3.x series compilers are supposed to do a much better job reducing bloat[2]. On my last project the code bloat wasn't as big of an issue because we were using the .cpp #include trick[3] to reduce compile times which should (theoretically) prevent the much of the bloat because of the (vastly) reduced number of .o files.
[2] The PS2 is exceptionally cache poor and can easily wind up major performance hits due to memory thrashing.
[3] You can have a .cpp file #include other .cpp files which will dramatically drop the total build time under gcc. The trick then becomes to group the .cpp files into mid sized groups that provide a good balance of rebuild times in the general case. Also, this can cause some very weird behavior due to #defines and statics having very different scopes from what you think they do. Note: clear the compile warnings out of your codebase before attempting this. Finding errors sandwiched between thousands of warning messages is a waste of your time.
wizard shit
Posted by: katy at June 3, 2003 11:57 AM