1This is a package of gcc-2.95.3 and binutils-2.15 for BeOS. 2Please consult the file "INSTALL" for info about how to install this package. 3 4This port is based on the work done by Takashi Toyoshima, which in turn is 5based on the official gnupro-releases done by Fred Fish and others at Be. 6Thanks to these guys and thanks to everyone who helped testing this new release! 7 8Lots of patches have been applied to get gcc-2.95.3 working properly on BeOS, 9you can find the gory details in the cvs-log-archives. 10 11 12 13These are the main changes: 14 15 - this gcc-2.95.3 won't crash just because one is using iostreams and/or STL. 16 17 - an improved and less buggy libstdc++.r4.so is included (with new headers). 18 19 - the tool-chain now defaults to B_LOW_PRIORITY, such that you can do other 20 things while a large build is running. Thanks to Andrew Bachmann for 21 suggesting this. You can override the default with -priority=<prio>. 22 23 - optimization is much more reliable now (it really is a bad idea to 24 use -O2 or -O3 with older compilers, as the likelihood of things going 25 very wrong is high!). 26 This port should be more reliable when using -O2 or even -O3, but: YMMV! 27 28 - new html-documentation is included for all tools. 29 30 - the gcc-option '-shared' is now working again, '-nostart' is a (BeOS- 31 specific) synonym for it. 32 33 34Bugs/Peculiarities: 35 36 - the default specs no longer include -lnet on R5, so some projects that are 37 relying on this implicit linking against libnet.so fail during linking 38 stage with messages like 'undefined reference to select' (or similar). 39 This can be fixed by explicitly adding -lnet to the build. 40 The reason for leaving out -lnet from the specs is that this is the way 41 things are done under Dano & Zeta and I'd like to avoid having to provide 42 different releases for each platform. 43 Anyway, if you really want to get back the original R5 behaviour, just change 44 the link 45 /boot/develop/tools/gnupro/lib/gcc-lib/i586-pc-beos/2.95.3-beos-xxx/specs 46 such that it points to specs.R5 and the R5-compatible specs should be active. 47 48 - gcc-2.95.3 (rightly) complains about code that calls delete on void*. This 49 code did not trigger any complaints with older compilers, but it probably 50 did not do what the programmer intended. If the pointer is in fact pointing 51 to an object, no destructors will be called, only the memory will be freed. 52 If that is the original intention, then the global operator delete should 53 be used instead: 54 void cleanup (void* cookie) 55 { 56 delete cookie; 57 } 58 becomes 59 void cleanup (void* cookie) 60 { 61 ::operator delete cookie; 62 } 63 If the destructor should be called, you have to cast the void* to the 64 appropriate type (or preferably get rid of that void* cruft). 65 66 - the linker goes out of its way to avoid generating relocation entries of 67 type R_386_NONE with an offset of 0, as this crashes the dynamic loader 68 of BONE/Dan0/Zeta. 69 Part of the dynamic loading process is the relocation of several entries 70 inside the binary to its real position in memory. The linker generates the 71 neccessary relocation entries, telling the loader for each relocation, what 72 kind of relocation is to be done (type) and where the relocation takes place 73 (offset into the binary-section). These relocation entries live in several 74 sections named ".rel."... 75 The linker from binutils-2.15 seems to do some more optimization than older 76 linkers, converting unneeded relocation-entries (pointing to sections that 77 were discarded during the link) to the R_386_NONE type, which in fact 78 means: "do nothing". The offset of these relocation entries is set to 0. 79 [Sidenote: it would be better to remove this entries altogether, but 80 that could change the size of an already layed-out section, which - 81 according to the binutils maintainers - is difficult, so the free space 82 is not yet reclaimed by ld]. 83 Now it seems that the newer dynamic loader is a bit peculiar about how to 84 handle these "do nothing" requests: it is perfectly happy to nothing at most 85 offsets, only offset 0 it doesn't like at all, as it then tries to execute 86 code like the following: 87 xor eax, eax 88 movl (eax), eax 89 which, naturally, crashes the machine. 90 The solution to this was to leave the original offset of these relocation 91 entries in place, just change the type to R_386_NONE. This hack seems to 92 work for all BeOS dynamic loaders. 93 94 - The Be-compilers had the habit of putting automatically generated functions 95 into each object file that uses them. This behaviour corresponds to what gcc 96 calls multiple symbol spaces. For ELF, however, multiple symbol spaces do 97 not make much sense, as all global symbols are automatically being exported 98 (i.e. there is only a single symbol space). 99 This version of gcc activates multiple symbol spaces only when optimization 100 is switched off. In optimizing mode, a single symbol space is used, in order 101 to yield smaller object files, libraries and apps. 102 You can use the new switch -f(no-)multiple-symbol-spaces to force gcc to 103 use (or not use) multiple symbol spaces. 104 105 - Every app is now automatically linked against a (new) object file named 106 fix_bdirectwin_typeinfo.o 107 As a result of the multiple / single symbol space issue, older compilers 108 generate typeinfo-functions in each object file that uses them (via 109 dynamic_cast). 110 As this compiler uses a single symbol space when optimizing, type-info 111 functions are not kept in each object file, but they are taken from the 112 library which "defines" the class that is the target of the dynamic_cast. 113 This works fine for most cases, but the Be-libraries seem to contain a 114 broken version of the BDirectWindow-typeinfo-function. 115 The difference here is that older compilers never used this function, as the 116 linker always linked to the (object-file-)internal version of this funtion. 117 Gcc-2.95.3 doesn't always generate these, so that the one living inside the 118 Be-libraries is being used, which in turn leads to a crash (examples are 119 GLTeapot or libSDL.so). 120 As a solution to this problem, I have created a new object file, named 121 fix_bdirectwin_typeinfo.o, that contains an implementation of the 122 BDirectWindow-typeinfo-funtion. Every app and library is now linked against 123 this file automatically (by means of the specs-file), such that the broken 124 implementation from the libs isn't used. 125 You can use the new switch -no-beos-fixes to switch off this fix. This is 126 especially useful if you are debugging small test applications and you do 127 not want/need the symbols from fix_bdirectwin_typeinfo.o. 128 What remains a mystery to me is to what respect this function is broken 129 and how it found its way into the libs in the first place... 130 131 - gcc-2.95.3 is a bit more decisive when it comes to the handling of inline 132 assembly operand constraints. The original gcc-2.95.3 contained a bug 133 (or two rather) that resulted in a complaint about a "fixed or forbidden 134 register" bx or bp being spilled for an inline asm-clause that requires 135 rather a lot of register operands. This bug has been fixed (i.e. bx and 136 bp are now only spilled if it is safe to do so), but it's still quite 137 probable that inline assembly that compiled and worked for gnupro-000224 138 may not compile instantly with gcc-2.95.3. 139 So far I have been able to fix all the inline assembly related problems by 140 specifying other operand constraints, but I wouldn't be surprised if there 141 are projects out there for which this won't work. 142 143 - the generation of debugging info has been, and still is, problematic. So 144 whenever you encounter weird error messages or other strange behaviour, 145 please try to deactivate debug-info (remove -g from the build). 146 I think it is especially unwise to combine optimization with debug-info 147 (which a lot of opensource projects seem to do by default), as this 148 combination seems to be the least reliable during compilation and the 149 resulting apps aren't useful in the debugger either. 150 151 - I believe 2.95.3 improves upon the other available compilers for BeOS, but 152 this does not mean that it is better for all purposes, it is just different! 153 So don't be surprised if you encounter internal compiler errors with code 154 that worked for gnupro-000224 or gnupro-991026. Please send me info about 155 any such cases so that I can *try* to work out a solution. 156 157Please send questions & bug-reports to: Oliver Tappe <gcc@hirschkaefer.de> 158