Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Wed, Aug 31, 2005 at 11:26:50AM -0400, Sergey A. Lipnevich wrote:
> Quoting Arwed von Merkatz <v.merkatz AT gmx.net>:
> 
> >> I propose moving both of these into test, with some time interval 
> >> between. The
> >> reason why OpenSSL 0.9.8 should go into test is because it doesn't break
> >> anything with very few exceptions (I found one and patched, 
> >> httpd-dev). The GCC
> >> 4 has to go because (a) most important stuff is patched or uses 
> >> gcc34 and (b) we
> >> now have spells in test that depend on gcc34 (e.g. ntp) while that 
> >> compiler is
> >> available as is already, which doesn't make sense. Also, I didn't check 
> >> but
> >> spells with dependency on gcc34 may have propagated into stable 
> >> already, where
> >> the compiler version is 3.3, which makes even less sense.
> >> What are your thoughts on this?
> >
> > I don't see any problem with the gcc34 spell, the spell clearly states
> > its only a placeholder.
> > I do have a problem with getting gcc 4.0.1 into test as it still
> > generates wrong code for several programs I know of and probably a lot
> > of programs I don't know of. It would also mean to get an unofficial glibc
> > snapshot into test, and that's something I'd really prefer not to do.
> 
> Alright. Please let me know if it's easier to fix these programs 
> somehow or roll
> back the change. The only problem I observed is a segfault for GECKO engine 
> on
> x86_64.

The biggest problem here is to actually identify the broken programs.
They can then be fixed by using gcc34 or in some cases by removing
several optimization options. Such brokenness can be really subtle, e.g.
for libebml 64bit integer reads and writes return a wrong value if the
library is compiled with any optimization setting higher than -01.
Segfaulting stuff is a lot easier to find than that ;)

> The biggest thing by far is the glibc. I understand using gcc34 doesn't 
> help. Is
> there anything I can do, or help you or anyone who's looking into that, 
> to make
> glibc and gcc 4 coexist in test?
 
So far my idea was to wait for the next official glibc release, though
that might be unrealistic as they don't like doing releases. Another
solution would be to figure out _why_ it fails to compile even if told
to use gcc34, which is a complete mistery to me.

For now I'll revert the gcc 4.0.x integration.

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org