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