requirements for default nightly & release builds on linux
Dan Mosedale
Linux have been built on Red Hat 6.2, using egcs 1.1.2, and compiled
with -O. This is a very dated configuration and that OS itself will be
designated as end-of-lifed by RedHat at the end of this month; see
<http://www.redhat.com/apps/support/errata/>. There are a whole bunch
of reasons that we want to start building with newer compilers and
libraries, the biggest among them are supportability and performance.
So we're at a point where we need to select what version of the OS (and
compilers and binutils and glibc etc) we want to switch to.
Most importantly, we want to use gcc 3.2 or better. This allows us to
use a stable C++ ABI, and will allow us to use -O2 to optimize builds of
mozilla. gcc 3.2.* entrains a bunch of other dependencies as well:
libgcc_s.so, glibc, libstdc++, and even (potentially) newer versions of
binutils.
The question at hand is this: what version of Red Hat should the default
builds be done on? 7.1 has been proposed, as has 7.3.
In general, we can't count on a browser built against newer libraries to
run on an older OS without those libraries (though in some cases that
may work).
The older the version chosen, the more existing users can continue to
download and use nightlies and releases directly. The newer the version
chosen, the less issues with build component dependencies, better
performance (newer compiler & binutils features will automagically be
taken advantage of), and we may be able to wait longer before going
through this process again. What I'm especially interested in
soliciting feedback for is:
* any interesting usage data about the various Linux versions (all vendors)
* thoughts on whether 7.1 or 7.3 would be a better choice, and why....
Note that this decision is not about dropping support for older
compilers. Anyone will still be able to pull from the CVS tree and
build using existing compilers, at least for now. Moreover, mozilla.org
does accept contributed builds, so it's not as though people won't be
able to use mozilla on older OSes and compilers.
Dan
KaiRo - Robert Kaiser
> compilers and binutils and glibc etc) we want to switch to.
> Most importantly, we want to use gcc 3.2 or better. This allows us to
> use a stable C++ ABI, and will allow us to use -O2 to optimize builds of
> mozilla.
Did you read the last post of Jan Varga in n.p.m.performance (about
gcc-3.4)?
Would a gcc-3.4 build run on a gcc-3.2 system? If 3.4 is compatible with
3.2 ABI-wise, we should consider moving straightly to 3.4 on the build
machines, IMHO. If the numbers of Jan's are really accurate, it might be
worth that step (major perf boost).
Note that gcc-3.2 is only supported on quite new versions of all distros
(don't know about others, but SuSE only supports it in 8.1, which
happens to be only the newest version, even though a 8.2 might happen
soon), so we really should have at least a .tar.gz build compiled with
at most gcc-2.96.x for all releases.
From my knowledge of Mozilla development, I don't expect that compiler
move to really happen before 1.4 final, though, and we'll see how far
the distros have improved on adopting gcc>=3.2 then...
I think the move to a newer Linux compiler has been tried too often now
without seeing any real change though. We should really do it (tm) this
time. Perhaps it'd be somehow possible to set up a tinderbox + build box
which also puts up nightly binaries to ftp.m.o, so people have a chance
to try those builds for a while, before we're flipping the main builds.
I guess we'd have a chance to try using 3.4 there as well, and step back
to 3.2.x if we're seeing problems.
Well, and then there's the Java problem, which will get solved soon (at
least from what Sun people tell us), but is unresolved as of now...
Robert Kaiser
Andrew Schultz
> The older the version chosen, the more existing users can continue to
> download and use nightlies and releases directly. The newer the version
> chosen, the less issues with build component dependencies, better
> performance (newer compiler & binutils features will automagically be
> taken advantage of), and we may be able to wait longer before going
> through this process again. What I'm especially interested in
> soliciting feedback for is:
I'm not sure what performance benefit you'll get from simply building on a
more recent distro. In either case (7.1 or 7.3), you're going to have to
use your own compiler & binutils (all 7.x ship with gcc 2.96). What am I
missing?
--
------------------------------------------------------------------
Andrew Schultz | The views expressed might
ajsc...@eos.ncsu.edu | not represent those of NCSU.
http://www4.ncsu.edu/~ajschult/ | They are however, correct.
Dan Mosedale
>> So we're at a point where we need to select what version of the OS
>> (and compilers and binutils and glibc etc) we want to switch to.
>> Most importantly, we want to use gcc 3.2 or better. This allows us to
>> use a stable C++ ABI, and will allow us to use -O2 to optimize builds
>> of mozilla.
>
>
> Did you read the last post of Jan Varga in n.p.m.performance (about
> gcc-3.4)?
>
Yeah, excellent.
> Would a gcc-3.4 build run on a gcc-3.2 system? If 3.4 is compatible with
> 3.2 ABI-wise, we should consider moving straightly to 3.4 on the build
> machines, IMHO. If the numbers of Jan's are really accurate, it might be
> worth that step (major perf boost).
Well, 3.3 hasn't even been released yet, let alone 3.4. He must have
been testing snapshot builds. But because the ABI is now stable (newer
versions can be forced to create 3.2-ABI-compatibile executables, if
necessary), it should be easy enough to upgrade when those versions are
available without any effect on end-users other than increased
performance. Assuming we don't run into any dependency problems (eg
glibc versions). This is one place where picking a newer OS would help
us, since that would make a newer library versions a requirement.
> Note that gcc-3.2 is only supported on quite new versions of all distros
> (don't know about others, but SuSE only supports it in 8.1, which
> happens to be only the newest version, even though a 8.2 might happen
> soon),
Yes, this is indeed the rub.
> so we really should have at least a .tar.gz build compiled with
> at most gcc-2.96.x for all releases.
Perhaps this is what we'll need to do. Build folks, would it be hard to
have a build with egcs still built and shipped nightly, even if it's the
not the main thing that QA focusses on?
> From my knowledge of Mozilla development, I don't expect that compiler
> move to really happen before 1.4 final, though, and we'll see how far
> the distros have improved on adopting gcc>=3.2 then...
No, we need to do this now (1.4 alpha) so that we have time to shake out
the various issues that are likely crop up.
> I think the move to a newer Linux compiler has been tried too often now
> without seeing any real change though. We should really do it (tm) this
> time. Perhaps it'd be somehow possible to set up a tinderbox + build box
> which also puts up nightly binaries to ftp.m.o, so people have a chance
> to try those builds for a while, before we're flipping the main builds.
> I guess we'd have a chance to try using 3.4 there as well, and step back
> to 3.2.x if we're seeing problems.
>
> Well, and then there's the Java problem, which will get solved soon (at
> least from what Sun people tell us), but is unresolved as of now...
Actually, Blackdown has released a 3.2-compiled version, so the general
problem is solved. Someone from Sun has also said in
http://bugzilla.mozilla.org/show_bug.cgi?id=116444#c85 that version
1.4.2 of the JRE will be gcc compatible.
Dan
Andrew Schultz
> gcc-3.4)?
>
> Would a gcc-3.4 build run on a gcc-3.2 system? If 3.4 is compatible with
> 3.2 ABI-wise, we should consider moving straightly to 3.4 on the build
> machines, IMHO. If the numbers of Jan's are really accurate, it might be
> worth that step (major perf boost).
gcc 3.4 is still under active development... If we wait until gcc 3.4 is
rock solid, gcc 3.6 will be under development and I have no doubt it will
be even faster than 3.4.
Just do it.
I'm sure gcc 3.4 is wonderful, but if it means waiting an additional day
before the switch, I say "go with 3.2"
> Note that gcc-3.2 is only supported on quite new versions of all distros
> (don't know about others, but SuSE only supports it in 8.1, which
> happens to be only the newest version, even though a 8.2 might happen
> soon), so we really should have at least a .tar.gz build compiled with
> at most gcc-2.96.x for all releases.
> From my knowledge of Mozilla development, I don't expect that compiler
> move to really happen before 1.4 final, though, and we'll see how far
> the distros have improved on adopting gcc>=3.2 then...
regardless of how many distros have gcc 3.2 or gcc 3.4 at that point,
Mozilla can't just drop people still running older versions without gcc 3.x
at all. AFAIK, the idea is that the relevant libraries (libstdc++, libgcc,
etc) would be linked in statically so that people running older distros
would be able to continue using the latest/greatest version of Mozilla.
Dan Mosedale
> Dan Mosedale wrote:
>
>> The older the version chosen, the more existing users can continue to
>> download and use nightlies and releases directly. The newer the
>> version chosen, the less issues with build component dependencies,
>> better performance (newer compiler & binutils features will
>> automagically be taken advantage of), and we may be able to wait
>> longer before going through this process again. What I'm especially
>> interested in soliciting feedback for is:
>
>
> I'm not sure what performance benefit you'll get from simply building on
> a more recent distro. In either case (7.1 or 7.3), you're going to
> have to use your own compiler & binutils (all 7.x ship with gcc 2.96).
> What am I missing?
>
Correct. We will have to get our own compiler. However, we need a
newer distribution to get a glibc and other things that are new enough
to support the compiler well. I believe the 7.x binutils are new enough
as well; do you know otherwise?
Dan
Andrew Schultz
> Correct. We will have to get our own compiler. However, we need a
> newer distribution to get a glibc and other things that are new enough
> to support the compiler well. I believe the 7.x binutils are new enough
> as well; do you know otherwise?
I built gcc 3.1 on 7.3 and I think that just building it required (at least
the RPM spec said so) a version of binutils that was newer than what was
shipped with 7.3 or available as an update.
7.1 shipped with glibc-2.2.2 Red Hat released glibc-2.2.4 as an update.
7.3 shipped with glibc-2.2.5
Are the differences between 2.2.4 & 2.2.5 significant enough to affect
compiler support?
Andrew Schultz
> Dan Mosedale wrote:
>
>> Correct. We will have to get our own compiler. However, we need a
>> newer distribution to get a glibc and other things that are new enough
>> to support the compiler well. I believe the 7.x binutils are new
>> enough as well; do you know otherwise?
>
>
> I built gcc 3.1 on 7.3 and I think that just building it required (at
> least the RPM spec said so) a version of binutils that was newer than
> what was shipped with 7.3 or available as an update.
more sleep, less crack.
I didn't build gcc3.1. A newer binutils was required to install the precompiled
binary RPM for gcc3.1.
Jon Granrose
> KaiRo - Robert Kaiser wrote:
>> so we really should have at least a .tar.gz build compiled with at
>> most gcc-2.96.x for all releases.
>
> Perhaps this is what we'll need to do. Build folks, would it be hard to
> have a build with egcs still built and shipped nightly, even if it's the
> not the main thing that QA focusses on?
The trunk is broken for egcs (1.1, IIRC) on our build systems which is
why we upgraded to gcc 2.95.3. That was a hassle which is why we need to
upgrade the build systems to RH 7.x. There are no plans for the
Netscape team to produce any build but what is decided on as the default
release build. Builds from mozilla.org contributors are always welcome.
I'm less concerned about what combination of libraries and compiler will
get us the optimum performance. That discussion could go on for months,
and I have 2 weeks, tops, to upgrade these systems. I'm most concerned
about what gives us the best foundation for ease of administration,
while still producing builds that can be run by the largest number of
users. egcs on RH 6.2 is not that. As far as I'm concerned going to
7.3 and gcc 2.95.3 or 2.96 is fine while this discussion continues on
what version of compiler and library is best in the future.
-j
Christopher Seawood
> Dan Mosedale wrote:
>
>> KaiRo - Robert Kaiser wrote:
>>
>>> so we really should have at least a .tar.gz build compiled with at
>>> most gcc-2.96.x for all releases.
I disagree. One of the primary reasons we didn't switch to gcc 2.95.3
is that it wasn't supported by *any* Red Hat release. None of them came
with the stdc++ libs used by gcc 2.95.3 and statically linking libstdc++
was not an option (unresolved licensing issues). I'm not all too
certain how well the current hack of building with gcc2.95.3 but linking
against the egcs stdc++ libs is going work in the long term. On the
flip side, we didn't use gcc 2.96 because it's *only* supported by Red
Hat (or RH-based) releases. That's hardly an improvement. Also, with
2.96, we lose C++ ABI compatibility with the previous egcs releases,
which means no java plugins. To my knowledge, no one has or plans to
release a 2.96 version of the plugin.
> The trunk is broken for egcs (1.1, IIRC) on our build systems which is
> why we upgraded to gcc 2.95.3. That was a hassle which is why we need to
> upgrade the build systems to RH 7.x. There are no plans for the
> Netscape team to produce any build but what is decided on as the default
> release build. Builds from mozilla.org contributors are always welcome.
As Jon pointed out, it's moderately easy for someone to contribute
nightlies for other compiler combinations if they wanted to. I'm not
convinced that we should concern ourselves with providing builds for the
older compiler which may or may not work.
> I'm less concerned about what combination of libraries and compiler will
> get us the optimum performance. That discussion could go on for months,
> and I have 2 weeks, tops, to upgrade these systems. I'm most concerned
> about what gives us the best foundation for ease of administration,
> while still producing builds that can be run by the largest number of
> users. egcs on RH 6.2 is not that. As far as I'm concerned going to
> 7.3 and gcc 2.95.3 or 2.96 is fine while this discussion continues on
> what version of compiler and library is best in the future.
If gcc 3.2 is what's claimed to give us a stable C++ ABI going forward
and we have resolved the Java plugin issue, we should start with the
latest version of the gcc 3.2 series, 3.2.2 and the latest version of
the RH7 series, 7.3. Otherwise, in the near future, we'll find
ourselves using a severely outdated compiler with a moderately outdated
build system (again).
- cls
Boris Zbarsky
set of instructions for upgrading the compiler _without_ upgrading the
OS for those of us who may still be using things like RedHat 6.2? Or
are the library dependencies such that any developers/contributors who
wish to continue working on Mozilla will need to upgrade their OS?
(Yes, I know there are no immediate plans to make things not build with
egcs; I give it about a week and a half after the switch for mozilla to
not build with egcs, just due to entropic considerations. It already
doesn't really build debug with egcs....)
Christopher Seawood
> regardless of how many distros have gcc 3.2 or gcc 3.4 at that point,
> Mozilla can't just drop people still running older versions without gcc
> 3.x at all. AFAIK, the idea is that the relevant libraries (libstdc++,
> libgcc, etc) would be linked in statically so that people running older
> distros would be able to continue using the latest/greatest version of
> Mozilla.
We've had several discussions about that and it has yet to be resolved
whether we can safely link libstdc++ & libgcc into our application.
Considering that we're going to be dropping support for a class of
platforms (RH6.x/glibc2.1), that should not even be a concern here. I'd
say that the chances are very high that whomever doesn't have libgcc
(which shipped with RH7.0) will not have the other required dependencies
as well (glibc2.2, in particular).
We're going to have shared library dependencies upon whatever version of
glibc & XFree86 that RH7.x uses. I've never understood why we keep
treating libstdc++ and now libgcc as special cases. Running
"out-of-the-box" is not always possible. The one time cost of
installing a shared library is not high enough that we should be
considering degrading our release build environment because of it.
- cls
Christian Biesinger
> As we move forward with this compiler change, could we possibly create a
> set of instructions for upgrading the compiler _without_ upgrading the
> OS for those of us who may still be using things like RedHat 6.2?
Hm, last time I built GCC it was rather straightforward...
(that was with linuxfromscratch though)
maybe http://www.at.linuxfromscratch.org/view/4.0/chapter05/gcc.html is
helpful even for a non-lfs system.
Christian Biesinger
> I'm sure gcc 3.4 is wonderful, but if it means waiting an additional day
> before the switch, I say "go with 3.2"
y'know, there will be a GCC 3.3 in between 3.2 and 3.4...
Darren Salt
> Andrew Schultz wrote:
[snip]
>> I'm not sure what performance benefit you'll get from simply building on a
>> more recent distro. In either case (7.1 or 7.3), you're going to have to
>> use your own compiler & binutils (all 7.x ship with gcc 2.96). What am I
>> missing?
> Correct. We will have to get our own compiler. However, we need a newer
> distribution to get a glibc and other things that are new enough to support
> the compiler well. I believe the 7.x binutils are new enough as well [...]
The versions in Debian as of 12 March, less the Debian revision numbers:
woody sarge sid
(stable) (testing) (unstable)
gcc 2.95.4 2.95.4 3.2.2
glibc (libc6) 2.2.5 2.3.1 2.3.1
binutils 2.12.90.0.1 2.13.90.0.10 2.13.90.0.18
libgcc (libgcc1) 3.0.4 3.2.1 3.2.3
... binutils *7*.x? <gd&r>
--
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| RISC OS, | s zap,tartarus,org | Northumberland
| Linux | @ | Toon Army
| We've got Shearer, you haven't
"Could you continue your petty bickering? I find it most interesting."
Christopher Blizzard
>
>> I'm less concerned about what combination of libraries and compiler
>> will get us the optimum performance. That discussion could go on for
>> months, and I have 2 weeks, tops, to upgrade these systems. I'm most
>> concerned about what gives us the best foundation for ease of
>> administration, while still producing builds that can be run by the
>> largest number of users. egcs on RH 6.2 is not that. As far as I'm
>> concerned going to 7.3 and gcc 2.95.3 or 2.96 is fine while this
>> discussion continues on what version of compiler and library is best
>> in the future.
>
>
> If gcc 3.2 is what's claimed to give us a stable C++ ABI going forward
> and we have resolved the Java plugin issue, we should start with the
> latest version of the gcc 3.2 series, 3.2.2 and the latest version of
> the RH7 series, 7.3. Otherwise, in the near future, we'll find
> ourselves using a severely outdated compiler with a moderately
> outdated build system (again).
It's ABI is "mostly stable." There are some expected ABI changes coming
down the pipe, but they relate to some obscure C++ features that we
don't actually use. I haven't looked at it in depth, so I could be
wrong about that.
If I remember correctly, the compiler actually warns if you end up
creating a structure that will change in the future if you use -Wabi on
a recent compiler.
--Chris
Dan Mosedale
> I demand that Dan Mosedale may or may not have written...
>
>
>>Andrew Schultz wrote:
>
> [snip]
>
>>>I'm not sure what performance benefit you'll get from simply building on a
>>>more recent distro. In either case (7.1 or 7.3), you're going to have to
>>>use your own compiler & binutils (all 7.x ship with gcc 2.96). What am I
>>>missing?
>
>
>>Correct. We will have to get our own compiler. However, we need a newer
>>distribution to get a glibc and other things that are new enough to support
>>the compiler well. I believe the 7.x binutils are new enough as well [...]
>
>
> The versions in Debian as of 12 March, less the Debian revision numbers:
> woody sarge sid
> (stable) (testing) (unstable)
> gcc 2.95.4 2.95.4 3.2.2
> glibc (libc6) 2.2.5 2.3.1 2.3.1
> binutils 2.12.90.0.1 2.13.90.0.10 2.13.90.0.18
> libgcc (libgcc1) 3.0.4 3.2.1 3.2.3
I suspect (but don't know) that the libgcc in woody will not be new
enough to run gcc 3.2 binaries. It's unclear from reading various gcc
documentation whether linking libgcc statically would solve this problem
without creating others.
>
> ... binutils *7*.x? <gd&r>
>
By this I meant "the versions of binutils that come with Red Hat 7.x".
Whether or not the binutils are new enough to build with, they aren't
required to use executables built by gcc 3.2 (as far as I know), so that
shouldn't be a big deal.
Dan
Dan Mosedale
> Christopher Seawood wrote:
>
>>
>>> I'm less concerned about what combination of libraries and compiler
>>> will get us the optimum performance. That discussion could go on for
>>> months, and I have 2 weeks, tops, to upgrade these systems. I'm most
>>> concerned about what gives us the best foundation for ease of
>>> administration, while still producing builds that can be run by the
>>> largest number of users. egcs on RH 6.2 is not that. As far as I'm
>>> concerned going to 7.3 and gcc 2.95.3 or 2.96 is fine while this
>>> discussion continues on what version of compiler and library is best
>>> in the future.
>>
>>
>>
>> If gcc 3.2 is what's claimed to give us a stable C++ ABI going forward
>> and we have resolved the Java plugin issue, we should start with the
>> latest version of the gcc 3.2 series, 3.2.2 and the latest version of
>> the RH7 series, 7.3. Otherwise, in the near future, we'll find
>> ourselves using a severely outdated compiler with a moderately
>> outdated build system (again).
>
>
> It's ABI is "mostly stable." There are some expected ABI changes coming
> down the pipe, but they relate to some obscure C++ features that we
> don't actually use. I haven't looked at it in depth, so I could be
> wrong about that.
As far as I know, that's still correct. But in addition...
> If I remember correctly, the compiler actually warns if you end up
> creating a structure that will change in the future if you use -Wabi on
> a recent compiler.
That's true, but also, 3.3+ will be able to force 3.2 ABI binaries to be
built by specifying -fabi-version=1. So we have now have a completely
stable API that we can use, even if it's not necessarily completely correct.
Dan
Dan Mosedale
> As we move forward with this compiler change, could we possibly create a
> set of instructions for upgrading the compiler _without_ upgrading the
> OS for those of us who may still be using things like RedHat 6.2? Or
> are the library dependencies such that any developers/contributors who
> wish to continue working on Mozilla will need to upgrade their OS?
It may be that gcc 3.2 will work on RH 6.2, I don't know. If someone
who still has 6.2 wants to try it and put together a doc, that'd be a
fine thing. However, we've entered a very twisty little maze of
intertwined dependencies, so I wouldn't be entirely surprised if
upgrading the OS was a significantly less painful path. :-/
Dan
Dan Mosedale
> Dan Mosedale wrote:
>
>> KaiRo - Robert Kaiser wrote:
>>
>>> so we really should have at least a .tar.gz build compiled with at
>>> most gcc-2.96.x for all releases.
>>
>>
>> Perhaps this is what we'll need to do. Build folks, would it be hard
>> to have a build with egcs still built and shipped nightly, even if
>> it's the not the main thing that QA focusses on?
>
>
> The trunk is broken for egcs (1.1, IIRC) on our build systems which is
> why we upgraded to gcc 2.95.3.
Ewww, really? I wasn't even aware of this.
> That was a hassle which is why we need to
> upgrade the build systems to RH 7.x. There are no plans for the
> Netscape team to produce any build but what is decided on as the default
> release build. Builds from mozilla.org contributors are always welcome.
>
> I'm less concerned about what combination of libraries and compiler will
> get us the optimum performance.
Well, a little long-term planning may save us some pain down the road.
> That discussion could go on for months,
Getting to an optimum place could take forever, but getting to a
significantly better than where we are now should be doable very
quickly, and I think we should get this landed for 1.4alpha if at all
possible.
> and I have 2 weeks, tops, to upgrade these systems. I'm most concerned
> about what gives us the best foundation for ease of administration, while
> still producing builds that can be run by the largest number of users.
Yes, this is clearly the important decision at hand.
> egcs on RH 6.2 is not that.
Indeed.
> As far as I'm concerned going to 7.3
7.1 is likely to allow the builds to run on the systems of more users
than 7.3, because an earlier version of glibc will be dynamically linked
against. 7.3-linked builds might work on earlier versions, or they
might not.
> and gcc 2.95.3 or 2.96 is fine while this discussion continues on
> what version of compiler and library is best in the future.
2.96 is a RedHat only compiler, so we'll do better to stick to 2.95.x if
we're not going to 3.2 immediately.
Dan
Bradley Baetz
>
> That's true, but also, 3.3+ will be able to force 3.2 ABI binaries to be
> built by specifying -fabi-version=1. So we have now have a completely
> stable API that we can use, even if it's not necessarily completely correct.
In addition, we don't trigger any of the -Wabi warnings in 3.2, which
suggests that we aren't affected by them. They are generally fairly
obscure; stuff like whether T<1+1> and T<2> are mangled the same, for
example. There are some virtual inheritance issues, but we don't use that
either.
>
> Dan
>
Bradley
Bradley Baetz
>
> The trunk is broken for egcs (1.1, IIRC) on our build systems which is
> why we upgraded to gcc 2.95.3. That was a hassle which is why we need to
> upgrade the build systems to RH 7.x. There are no plans for the
> Netscape team to produce any build but what is decided on as the default
> release build. Builds from mozilla.org contributors are always welcome.
Eww. Was there a bug on that? Also, there was an implication in another
subthread that you're linking to the egcs libstc++. I'm amazed that that
even works, although I guess we don't really use libstdc++ for much.
> I'm less concerned about what combination of libraries and compiler will
> get us the optimum performance. That discussion could go on for months,
> and I have 2 weeks, tops, to upgrade these systems. I'm most concerned
> about what gives us the best foundation for ease of administration,
> while still producing builds that can be run by the largest number of
> users. egcs on RH 6.2 is not that. As far as I'm concerned going to
> 7.3 and gcc 2.95.3 or 2.96 is fine while this discussion continues on
> what version of compiler and library is best in the future.
Well, thats true. As others have said, though, 3.2 is the only way to go.
The compiler isn't the issue so much as the base system - we can easily
install an upgraded compiler, and will in fact have to for the reasons
given by others.
I'm sort of with the people who are suggesting upgrading to RH8.0, using
gcc-3.2, and just requiring users to install appropriate versions of
libsupc++/libstdc++/libgcc.so. At the same time, mozilla does heavily rely
on nighly testers a lot (more so than a lot of other projects, I suspect),
and, while nothing is stopping anyone else doing nightly builds, I suspect
its unlikely to happen on the daily/twice daily basis which Netscape
produces builds. Not to mention that gcc-2.95 has that
nsCOMPtr-declared-in-while bug in optimised builds which rears its head
every so often, although I don't recall seeing a bug report on that for a
while.
>
> -j
>
Bradley
Boris Zbarsky
> Most importantly, we want to use gcc 3.2 or better.
Have we talked to RealNetworks about a version of RealPlayer that will
work with such builds? It's good to have Java in hand, but there have
been fewer problem reports about Java with the 1.3 builds than there
have been with RealPlayer (the 1.3 RPMs are built with gcc 3.2)...
Not that this should stop us, but we may want to give them a heads-up so
that when we ship they have a working version of RealPlayer for us....
Jon Granrose
FYI, the current plan of action is to upgrade our branch and trunk build
systems to RH 7.1 and gcc 2.95.3. Once we're sure those builds work, we
will upgrade our branch build system to gcc 3.2.2. We will be able to
produce both 2.95.3 and 3.2.2 nightly builds so that people can test
both of them for several weeks and make sure there aren't any issues
with 3.2.2 builds before switching over. We may or may not have gcc
3.2.2 builds available for mozilla 1.4a depending on how smoothly the
process goes.
-j
Dennis Haney
Dan> This allows us to use a stable C++ ABI, and will allow us to use
Dan> -O2 to optimize builds of mozilla.
May I suggest adding -march=pentium-mmx on the i386 architecture to
produce pentium instructions, (the pentium is already a requirement in
the release notes and 200MHz+ all have mmx instructions[1][2], so it
shouldn't affect any users?) and a -mcpu=pentium2 to optimize for a
sligthly newer[3] cpu without utilizing its instruction set?
[1] http://www6.tomshardware.com/cpu/20030217/images/cpu_chart.gif
and http://www6.tomshardware.com/cpu/20030217/index.html
[2] even though utilizing those also requires -mmmx AFAIK.
[3] It already has 5 years on its back, time moves fast :D
--
Dennis
use Inline C => qq{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
Boris Zbarsky
> May I suggest adding -march=pentium-mmx on the i386 architecture to
> produce pentium instructions, (the pentium is already a requirement in
> the release notes and 200MHz+ all have mmx instructions[1][2], so it
> shouldn't affect any users?) and a -mcpu=pentium2 to optimize for a
> sligthly newer[3] cpu without utilizing its instruction set?
Does that include AMD cpus? Those have MMX support? (And I know we
have some users on 486, though not many....)
Andrew Schultz
Current AMD CPUs (athlon) fully support MMX / MMX II. Older ones (K6) had MMX.
see also http://bugzilla.mozilla.org/show_bug.cgi?id=53486#c79
Bradley Baetz
>>>>>> "Dan" == Dan Mosedale <dm...@mozilla.org> writes:
>
>Dan> This allows us to use a stable C++ ABI, and will allow us to use
>Dan> -O2 to optimize builds of mozilla.
>
> May I suggest adding -march=pentium-mmx on the i386 architecture to
> produce pentium instructions,
Lets get -O2 working first.... Then we can measure the changes (if any)
Bradley
Dan Mosedale
> Dan Mosedale wrote:
>
>> Most importantly, we want to use gcc 3.2 or better.
>
>
> Have we talked to RealNetworks about a version of RealPlayer that will
> work with such builds? It's good to have Java in hand, but there have
> been fewer problem reports about Java with the 1.3 builds than there
> have been with RealPlayer (the 1.3 RPMs are built with gcc 3.2)...
>
As we discussed in #mozilla, this must be a different problem with the
1.3 RPMs, perhaps the use of GTK2. I just built a gcc 3.2.2 build
fresh, and the RealPlayer 8 plugin works nicely with it.
Dan
Darren Salt
[snip]
> IMHO, RedHat 8.0 should be the version that you are compiling nightly and
> milestone versions, especially given that RH8.1 is shortly to be released -
> and especially because all upgrades to RedHat are freely downloadable from
> the WWW.
If it uses gcc 2.95.x (or the RH special) and glibc 2.2.x, then yes, I'll
agree.
If it uses gcc 3.2 or glibc 2.3.x, then you should wait for six months then
ask again.
> It's not such a great difficulty to upgrade.
You appear to be assuming that there's only one distribution out there :-|
> Personally, as soon as RH8.1 is released I'll be buying the latest
> official CDs and upgrading. $60 is not expensive for RH8.1
It's maybe not expensive for Red Hat, but it'd be expensive for Debian; 3.0r1
(binaries, 7 CDs) can be had for £14.
> I might add that if people are concerned about upgrade issues, then how
> about creating a directory on the FTP server containing all the upgraded
> components that will be necessary for running the new builds.
And what about resources for other distributions? How do you plan to handle
security updates?
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| This space reserved for future expansion
Windows 98. Midnight reboot - is it today, tomorrow or yesterday?
Darren Salt
> On Sat, 22 Mar 2003 22:04:32 +0000, Darren Salt wrote:
>> And what about resources for other distributions? How do you plan to
>> handle security updates?
> Not speaking of distributions here.
So why were you referring only to Red Hat and making assumptions about what
other people are using?
> Speaking of the needed gizumped tarballs that can be downloaded and
> installed.
ITYM "gzipped" or "bzipped".
> That's how I installed Mozilla - using the tarball.
> The RPM was trying to update parts of Mozilla that I didn't have installed
> - and so it spat the dummy.
Hmm? Surely if you installed from tarball (only), then the RPM database
wouldn't have any record of Mozilla being installed, and this wouldn't be a
problem?
You /did/ unpack it into /usr/local/mozilla...?
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| ZapEmail. ZapDS. MakeExtern.
When I'm not in my right mind, my left mind gets pretty crowded.
Darren Salt
> On Sat, 22 Mar 2003 22:04:32 +0000, Darren Salt wrote:
>> It's maybe not expensive for Red Hat, but it'd be expensive for Debian;
>> 3.0r1 (binaries, 7 CDs) can be had for Ł14.
> 14 quid is not all that different from $60.
> Take ŁŁŁ and multiply it by 3 and you've got $$$
> Probably won't work if you're thinking american $$$
But if you don't say which $ then, unless you're in the country whose
currency that is, US$ is generally a reasonable assumption...
(Silly me. I hadn't noticed the NNTP-Posting-Host header, naming an NZ-based
server...)
--
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| RISC OS, | s zap,tartarus,org | Northumberland
| Linux | @ | Toon Army
| Retrocomputing: a PC card in a Risc PC
No it isn't!
Darren Salt
> On Mon, 24 Mar 2003 00:49:05 +0000, Darren Salt wrote:
>> But if you don't say which $ then, unless you're in the country whose
>> currency that is, US$ is generally a reasonable assumption.
> Nope - sorry - wrong!
How so?
--
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| RISC OS, | s zap,tartarus,org | Northumberland
| Linux | @ | Toon Army
| Wanted: PRM v5a
(Ice rocks hit the hull) "Captain, we are being hailed."
Darren Salt
> On Mon, 24 Mar 2003 00:49:34 +0000, Darren Salt wrote:
>> You /did/ unpack it into /usr/local/mozilla...?
> Don't tell me what I did!
I didn't then, but I will now: you've failed to realise the significance of
that question mark...
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| This space reserved for future expansion
No problem is so formidable that you can't just walk away from it.
Darren Salt
> On Mon, 24 Mar 2003 00:49:34 +0000, Darren Salt wrote:
>> ITYM
> What?
"I think [that] you mean"...
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| ChrEd. AppSquash. BlockSize. Decoders. FontMsgs.
CAD: Can't Anybody Draw?
Nicolas Pioch
issues, RPMs, glibc, etc.
I was wondering if it wouldn't be a good idea to fork a sub-newsgroup,
either
netscape.public.mozilla.linux
or
netscape.public.mozilla.unix.linux
devoted to these mysterious linux-specific issues that do not occur on
other unix platforms ?
Darren Salt
> On Mon, 24 Mar 2003 00:49:34 +0000, Darren Salt wrote:
>>> Not speaking of distributions here.
>> So why were you referring only to Red Hat and making assumptions about
>> what other people are using?
> I referred to RedHat 8.0, because it's the most common distribution, and
> because it is a recent version.
Fair enough. But you could have indicated that it was picked as an example.
> I would expect that necessary software component versions would be provided
> in tarballs for those who don't use the RedHat Package manager, and in RPMs
> for those who do.
Which is why I asked about security updates... OTOH, links to resources such
as an apt-gettable archive of backports of libraries for woody would be much
better than providing just tarballs.
And even with RPM, does one size fit all...?
[snip repeat]
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| Spr2Png. MergeSprs.
Man who bites bread or eats peas with knife is lost creature.
Jon Granrose
FYI, starting last night (3/26) at 8pm, the daily trunk verification
builds are being produced on a RH 7.3 system with gcc 2.95.3.
Please let us know if you notice anything unexpected.
Thanks,
Christopher Seawood
>
> FYI, starting last night (3/26) at 8pm, the daily trunk verification
> builds are being produced on a RH 7.3 system with gcc 2.95.3.
>
> Please let us know if you notice anything unexpected.
From about:buildconfig :
gcc gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
c++ gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
about:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030327
Building with 2.96 seems unintentional; it also means that existing
xpcom plugins will be incompatible since the c++ abi changed from
egcs/gcc2.95 . The java plugin works if you're using the version of the
jdk that shipped with RH7.x.
- cls
Christopher Blizzard
> From about:buildconfig :
>
> gcc gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
> c++ gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
Woah! Since when have we had about:buildconfig? We should put that on
the bugzilla helper page, if it isn't there already.
--Chris
Christopher Seawood
Bug 140034 landed shortly after we opened the tree for 1.4a. Yes, a
note about using about:buildconfig should be be added to the helper pages.
- cls
Bradley Baetz
>
> FYI, starting last night (3/26) at 8pm, the daily trunk verification
> builds are being produced on a RH 7.3 system with gcc 2.95.3.
Please don't do that. This gives us all the pains of upgrading (and more,
since 2.95 buidls won't work with redhat, but 2.96 builds won't work on
other distributions. And ISTR comeone mentioning legal issues with
staticly linking libstdc++ before 3.0, so that fix won't work), but with
none of the benefits (since 2.95 can't use -O2 either). Just go the whole
way to 3.2, and (hopefully) we'll be done with it.
Bradley
Darren Salt
> On Tue, 25 Mar 2003 15:35:35 +0000, Darren Salt wrote:
>> And even with RPM, does one size fit all...?
> Yes - of course!
> Only latest versions of GPL licensed, freely downloadable, software should
> be supported.
So when a new glibc is released, you immediately drop support for the
previous version? ... oh, wait, that's LGPL and therefore shouldn't be
supported...
:->
> Thus, only RPMs for the latest version of RedHat/Mandrake.
> And yes - I agree - the archive should be apt-getable.
So *not* just RPMs, then.
> BTW, RH 9.0 is due out soon, and Mandrake 9.1 is now available.
Debian's next release (probably 4 rather than 3.1) might be out this year,
with any luck...
--
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| RISC OS, | s zap,tartarus,org | Northumberland
| Linux | @ | Toon Army
| Let's keep the pound sterling
Standard - excellence. Goal - perfection. Reality - Murphy.
Darren Salt
> On Tue, 25 Mar 2003 00:33:29 +0000, Darren Salt wrote:
>>> Don't tell me what I did!
>> I didn't then, but I will now: you've failed to realise the significance
>> of that question mark.
> A statement with a questionmark appended is STILL a statement and is NOT a
> question. Questions are formed by changing the order of subject and verb in
> the sentence.
> EG:
> You did sing.
> Did you sing?
"You did sing?" and "You did sing, didn't you?" are contractions of "You
should have sung. Did you?". You *did* realise that...?
> This is EXTREMELY basic English Grammar.
Yes, Mr. Missingspace :-)
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| When replying, "news"->"ds", "cu"->"co.uk", and validate
Complete and utter lie: "This'll only take five minutes."
Darren Salt
> On Tue, 25 Mar 2003 00:36:56 +0000, Darren Salt wrote:
>>>> But if you don't say which $ then, unless you're in the country whose
>>>> currency that is, US$ is generally a reasonable assumption.
>>> Nope - sorry - wrong!
>> How so?
> American $$$ is only ONE version of the dollar amongst many.
> It is not reasonable to assume one particular version over the others when
> in an international forum.
If that is not reasonable, then it is also not reasonable not to state which
version you mean when in an international forum.
(Which, basically, means that there are a *lot* of unreasonable USAnians...)
--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| RISC OS, | Northumberland | s zap,tartarus,org
| Linux | Toon Army | @
| JSW. Bug. CTetris. Mindtrap. KPatience. SnakePit.
Real Programmers never work 9 to 5. One around at 9am was up all night.
Boris Zbarsky
> Just go the whole way to 3.2, and (hopefully) we'll be done with it.
I have to second this. I see absolutely no reason to move from 2.95.3
on RH6 to 2.95.3 on RH7 -- we gain no benefits that I can see and we
lose potential testers who may be running RH6.
Is there a reason for this move that I'm missing?
Gervase Markham
> note about using about:buildconfig should be be added to the helper pages.
What would you like it to say? Should this info really be included in
_every_ bug report? If not, which ones?
Gerv
Boris Zbarsky
> What would you like it to say? Should this info really be included in
> _every_ bug report? If not, which ones?
It should be included in every Linux bug report that has to do with
events, painting, fonts, and whatever else may differ between the three
different types of Linux binaries we have...
Christopher Seawood
I suck at release notes. "Please include the build configuration of
your build which can be found at about:buildconfig ." ? Every bug
report. If a user is using the bugzilla helper to report the bug, I
have no faith that they will be able to determine when it's appropriate
to include that information.
- cls
Gervase Markham
> I suck at release notes. "Please include the build configuration of
> your build which can be found at about:buildconfig ." ? Every bug
> report. If a user is using the bugzilla helper to report the bug, I
> have no faith that they will be able to determine when it's appropriate
> to include that information.
In what percentage of bug reports is it actually useful information?
about:buildconfig is not small; I worry that we will bloat a lot of bug
reports with useless information.
If it's only a small proportion, is it not reasonable to ask for it in a
second round of information-gathering?
Gerv
Christopher Seawood
> In what percentage of bug reports is it actually useful information?
> about:buildconfig is not small; I worry that we will bloat a lot of bug
> reports with useless information.
I'd say roughly greater than the number of bugs where the build id is
considered useful information. Especially considering that not all
nightly builds use the standard build configuration
(/build/distribution.html). Are we looking at the same page?
about:buildconfig is tiny. You can limit it to just the build config
options if you want.
- cls
Andrew Schultz
> Gervase Markham wrote:
>
>> In what percentage of bug reports is it actually useful information?
>> about:buildconfig is not small; I worry that we will bloat a lot of bug
>> reports with useless information.
>
>
> I'd say roughly greater than the number of bugs where the build id is
> considered useful information.
This is true by far in the Build Config component, but outside that, the build
ID is invaluable. Outside Build Config, most bugs are XP and occur with any
build options.
> Especially considering that not all nightly builds use the standard build
> configuration
But most bugs are reported against the .mozilla.org binary builds, especially
those filed with bugzilla helper (again, outside Build Config component).
about:buildconfig would help out most in cases where people are using
non-default binaries (gtk2/xft RPMs) or creating their own build from source.
Boris Zbarsky
> about:buildconfig would help out most in cases where people are using
> non-default binaries (gtk2/xft RPMs) or creating their own build from
> source.
I would say that about 80% of the Linux bug reports I see are reported
with those builds... and in about 50% of those the information from
about:buildconfig is needed. Usually so they can be marked duplicate of
known gtk2/xft issues. ;)
Gervase Markham
> Gervase Markham wrote:
> considered useful information.
The build ID is useful information in _every_ bug, because it enables QA
to work out exactly when the problem is known to occur, check that the
person is not using a stupidly old build, and so on. It may not often be
useful for diagnosing the problem, but that's not the point of getting it.
> Especially considering that not all
> nightly builds use the standard build configuration
> (/build/distribution.html).
Which ones don't? Can we instead add a field where they say which build
they downloaded (from which the build options can be deduced)?
> Are we looking at the same page?
> about:buildconfig is tiny. You can limit it to just the build config
> options if you want.
Copying and pasting the Linux version of it into a Bugzilla comment box,
it takes up 16 lines. That's definitely non-trivial.
There are whole classes of bugs (e.g. front end bugs) where all that
info is irrelevant. Do we often have problems where we ask a reporter
"Please give us your build config" and we get ignored?
I'm not necessarily opposed to adding a note about this; I'm just
concerned about bloating bug reports with un-useful info, putting an
additional burden on bug reporters, and further complicating the bug
reporting page.
Gerv
Boris Zbarsky
> Which ones don't?
The RPMs. There are in fact several different types of RPMs, all
different from each other and from the tarball.
> Can we instead add a field where they say which build
> they downloaded (from which the build options can be deduced)?
That may be sufficient if done right.
> There are whole classes of bugs (e.g. front end bugs) where all that
> info is irrelevant.
That's actually not true, in my experience with XFT bugs.... As in,
some can tell when it may be relevant to a "front end" bug (that is,
some reporters can usually tell when a "front end" bug is really a bug
in the underlying gecko code), but most reporters can't do it, and a
number of manifestations of xft and especially gtk2 look decidedly
"front end".
> Do we often have problems where we ask a reporter
> "Please give us your build config" and we get ignored?
Yes. We also have trouble communicating to them what we mean -- it
usually takes 2-3 requests to get the info from a cooperative reporter.
Christopher Seawood
> Christopher Seawood wrote:
>
>> Gervase Markham wrote:
>> I'd say roughly greater than the number of bugs where the build id is
>> considered useful information.
>
>
> The build ID is useful information in _every_ bug, because it enables QA
> to work out exactly when the problem is known to occur, check that the
> person is not using a stupidly old build, and so on. It may not often be
> useful for diagnosing the problem, but that's not the point of getting it.
Except that unless you're using a nightly build that you know comes from
mozilla.org's ftp site and was put up there by the nighlty scripts run
by Granrose, the build id is practically useless. The build id has no
special correspondence to what's in the build. It just so happens that
the nightly scripts build immediately after pulling so there's almost a
direct correlation for those builds only. For bug reports that get
filed on any other builds of mozilla, the build id is misleading.
>> Especially considering that not all nightly builds use the standard
>> build configuration (/build/distribution.html).
>
>
> Which ones don't? Can we instead add a field where they say which build
> they downloaded (from which the build options can be deduced)?
If they don't come from the mozilla.org nightly build script, there's no
guarantee that they use the same build configuration. It's not a
requierment for uploading tarballs to the ftp site. If you want further
specifics, look at the READMEs in the tarballs as configurations can
change over time.
>> Are we looking at the same page? about:buildconfig is tiny. You can
>> limit it to just the build config options if you want.
>
>
> Copying and pasting the Linux version of it into a Bugzilla comment box,
> it takes up 16 lines. That's definitely non-trivial.
>
> There are whole classes of bugs (e.g. front end bugs) where all that
> info is irrelevant. Do we often have problems where we ask a reporter
> "Please give us your build config" and we get ignored?
Yes. about:buildconfig is new as of the week we opened for 1.4a.
Before that, we had no way of knowing what build config that version of
mozilla was using or any way to get that information short of
attempting to get the user to tell us the exact URL to the version they
downloaded (which oddly enough doesn't seem to always work) and hope it
contained a README which listed the non-standard build options.
- cls
Gervase Markham
> mozilla.org's ftp site and was put up there by the nighlty scripts run
> by Granrose, the build id is practically useless.
But the vast majority of bug reports are filed on those builds. And
self-built builds have (or had, last time I looked) a buildID of
00000000, so there's no confusion.
Perhaps this is the issue. We could ask people to include
about:buildconfig if they didn't get their build from the mozilla.org
FTP site. I'd be cool with that.
Gerv
Christopher Seawood
>> Except that unless you're using a nightly build that you know comes
>> from mozilla.org's ftp site and was put up there by the nighlty
>> scripts run by Granrose, the build id is practically useless.
>
>
> But the vast majority of bug reports are filed on those builds. And
Which is why we've been lucky so far. However, as more people build and
more vendors distribute mozilla and/or the GRE, those build ids are
going to become less useful. (Why bugs are being filed in moz.org's
bugzilla for vendor releases is a separate debate.)
> self-built builds have (or had, last time I looked) a buildID of
> 00000000, so there's no confusion.
Self-built builds aren't the only problem though. The vendor builds and
the nightly builds that mozilla.org doesn't directly control are a
concern as well. Also, note that because our build defaults are what's
"good" for developers (ie, --enable-debug), people are looking at
distribution.html for the recommended build options and that page says
to set the _OFFICIAL env variables which set the build id.
> Perhaps this is the issue. We could ask people to include
> about:buildconfig if they didn't get their build from the mozilla.org
> FTP site. I'd be cool with that.
Except that ftp.mozilla.org hosts multiple build configurations so it
shouldn't be exempt. Though, now that you mention it, I don't see
anywhere that we tell people to tell us where they got the build.
- cls
Christopher Blizzard
> Which is why we've been lucky so far. However, as more people build and
> more vendors distribute mozilla and/or the GRE, those build ids are
> going to become less useful. (Why bugs are being filed in moz.org's
> bugzilla for vendor releases is a separate debate.)
>
Is there an easy way that we can tell an "official Red Hat" version, for
example? I'm more than happy to stuff something in the buildid or the
configure line, if it would make it easier for you guys.
--Chris
Christopher Seawood
We discussed adding a vendor string to the build id back in bug 27698
but the thinking at the time was that the build id wasn't that important
for bug reports and the UserAgent was all that mattered so the patch was
dropped.
- cls
Christopher Blizzard
I'd rather not add any Red Hat-specific strings to the user agent field,
if possible (gecko is gecko is gecko, right?) So it's only really
important for bug reporting.
Can we add a VENDOR_ID to the build environment that would show up in
about:buildconfig? We could have "mozilla.org", "netscape" or "Red Hat"
as examples.
--Chris
Andrew Schultz
I've noticed in bugs with Debian builds (for instance), Mozilla reports
itself as:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3
which is helpful once you know that Debian is making gtk2/xft builds.
Galeon does something similar. If the Mozilla RPMs did something like
that, it would help out.