Has anyone managed to get FF 18.0 to work on Centos 5.8?
I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
and dunno either what I've done wrong, or what other things need to be brought over.
Clues appreciated. :)
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
and dunno either what I've done wrong, or what other things need to be brought over.
Clues appreciated. :)
Haven't quite figured it out yet. What has worked for me so far with the previous versions was a newer libstdc++ from, I think, Fedora 9 (libstdc++-4.3.0-8.x86_64.rpm). The issue with ff18 is related to nss somehow. I found some posts in a mozdev forum that make it look like ff18 is linked against nss 3.14.1 or .2 beta, but runnable against 3.14. Which is interesting because it appears to work on CentOS6, which has nss 3.13.5.
The next thing I was going to try was building a shared lib from nss-3.14.1 based on the nss 3.14.5 el5 srpm, but I have a feeling this may not be enough.
From: fred smith fredex@fcshome.stoneham.ma.us
Has anyone managed to get FF 18.0 to work on Centos 5.8? I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
I tried to update to 18, and it did not complain about libstd++... I think I only copied: libstdc++.so.6 -> libstdc++.so.6.0.10* libstdc++.so.6.0.10* No other lib or script... But 18 complained about: "Couldn't load XRE functions." Went back to 17.0.1 in the mean time...
JD
On Thu, Jan 10, 2013 at 02:29:02AM -0800, John Doe wrote:
From: fred smith fredex@fcshome.stoneham.ma.us
Has anyone managed to get FF 18.0 to work on Centos 5.8? I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
I tried to update to 18, and it did not complain about libstd++... I think I only copied: libstdc++.so.6 -> libstdc++.so.6.0.10* libstdc++.so.6.0.10* No other lib or script... But 18 complained about: "Couldn't load XRE functions."
Yeah, that's what I got, too. Someone on the mozilla site said that it requires a later glibc, which is what got me going on moving over glibc and glib package shared objects from a centos-6 box.
Went back to 17.0.1 in the mean time...
me too.
On 01/10/2013 07:16 AM, fred smith wrote:
On Thu, Jan 10, 2013 at 02:29:02AM -0800, John Doe wrote:
From: fred smith fredex@fcshome.stoneham.ma.us
Has anyone managed to get FF 18.0 to work on Centos 5.8? I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
I tried to update to 18, and it did not complain about libstd++... I think I only copied: libstdc++.so.6 -> libstdc++.so.6.0.10* libstdc++.so.6.0.10* No other lib or script... But 18 complained about: "Couldn't load XRE functions."
Yeah, that's what I got, too. Someone on the mozilla site said that it requires a later glibc, which is what got me going on moving over glibc and glib package shared objects from a centos-6 box.
Went back to 17.0.1 in the mean time...
me too.
You guys do know that we are fairly up2date with firefox/thunderbird on their ESR program right?
The Firefox/Thunderbird we have is totally updated for security and gets upstream support from Mozilla. It does not have every feature, but it has most and should stay on ESR.
On 01/10/2013 07:37 AM, Johnny Hughes wrote:
On 01/10/2013 07:16 AM, fred smith wrote:
On Thu, Jan 10, 2013 at 02:29:02AM -0800, John Doe wrote:
From: fred smith fredex@fcshome.stoneham.ma.us
Has anyone managed to get FF 18.0 to work on Centos 5.8? I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
I tried to update to 18, and it did not complain about libstd++... I think I only copied: libstdc++.so.6 -> libstdc++.so.6.0.10* libstdc++.so.6.0.10* No other lib or script... But 18 complained about: "Couldn't load XRE functions."
Yeah, that's what I got, too. Someone on the mozilla site said that it requires a later glibc, which is what got me going on moving over glibc and glib package shared objects from a centos-6 box.
Went back to 17.0.1 in the mean time...
me too.
You guys do know that we are fairly up2date with firefox/thunderbird on their ESR program right?
The Firefox/Thunderbird we have is totally updated for security and gets upstream support from Mozilla. It does not have every feature, but it has most and should stay on ESR.
More info:
On 01/10/2013 02:39 PM, Johnny Hughes wrote:
You guys do know that we are fairly up2date with firefox/thunderbird on
their ESR program right?
The Firefox/Thunderbird we have is totally updated for security and gets upstream support from Mozilla. It does not have every feature, but it has most and should stay on ESR.
Does the version bundled with Centos6 also track this schedule? It's currently 10.0.12 which made me decide to remove it from all desktop installations and install the newest on the fileserver. It's a bit of a hassle to do start though (the nice menu entries get lost as well).
On 01/10/2013 07:47 AM, Theo Band wrote:
On 01/10/2013 02:39 PM, Johnny Hughes wrote:
You guys do know that we are fairly up2date with firefox/thunderbird on
their ESR program right?
The Firefox/Thunderbird we have is totally updated for security and gets upstream support from Mozilla. It does not have every feature, but it has most and should stay on ESR.
Does the version bundled with Centos6 also track this schedule? It's currently 10.0.12 which made me decide to remove it from all desktop installations and install the newest on the fileserver. It's a bit of a hassle to do start though (the nice menu entries get lost as well).
Yes ... CentOS-5 and CentOS-6 are on ESR ... of course, we build what the release in RHEL sources.
But, my understanding of the plan is that they are staying on the ESR track, so they will upgrade 10 ESR to the new ESR before mozilla EOLs the current ESR.
17.x looks like it will be the next ESR.
WRT CentOS-5 specifically, we are in the middle of the 5.9 release so that 10.0.12.el5 is delayed for 1 or 2 days as it is built against 5.9 and not 5.8.
Our CR repo ( http://wiki.centos.org/AdditionalResources/Repositories/CR ) in the CentOS-5.8 tree should get the CentOS-5.9 updates in the next couple of days. That will be followed by the full release of 5.9 (including the ISOs) with a couple of weeks after that.
Does the version bundled with Centos6 also track this schedule? It's currently 10.0.12 which made me decide to remove it from all desktop installations and install the newest on the fileserver. It's a bit of a hassle to do start though (the nice menu entries get lost as well).
10.0.12esr is still supported (only released on Jan 8th in fact)...
On 10 January 2013 14:01, James Hogarth james.hogarth@gmail.com wrote:
Does the version bundled with Centos6 also track this schedule? It's
currently 10.0.12 which made me decide to remove it from all desktop installations and install the newest on the fileserver. It's a bit of a hassle to do start though (the nice menu entries get lost as well).
10.0.12esr is still supported (only released on Jan 8th in fact)...
Further to that according to the last Mozilla weekly planning meeting 10.0.12esr will be the last in the 10.0.X series... so expect Red Hat to release a 17.0.Xesr at some point in the next few months or so...
From: Johnny Hughes johnny@centos.org
You guys do know that we are fairly up2date with firefox/thunderbird on their ESR program right? The Firefox/Thunderbird we have is totally updated for security and gets upstream support from Mozilla. It does not have every feature, but it has most and should stay on ESR.
Yes; I mainly use the ESR version; but sometimes I wanna have fun and play a bit with the new features... Weird numbering, especially since the 10.0.x branch seems to stop at 10.0.8 (and apparently related to 18.x)... Did they go further (past their 2 release overlap) so that we don't have to switch to 17.0.x?
JD
On 01/10/2013 08:16 AM, John Doe wrote:
From: Johnny Hughes johnny@centos.org
You guys do know that we are fairly up2date with firefox/thunderbird on their ESR program right? The Firefox/Thunderbird we have is totally updated for security and gets upstream support from Mozilla. It does not have every feature, but it has most and should stay on ESR.
Yes; I mainly use the ESR version; but sometimes I wanna have fun and play a bit with the new features... Weird numbering, especially since the 10.0.x branch seems to stop at 10.0.8 (and apparently related to 18.x)... Did they go further (past their 2 release overlap) so that we don't have to switch to 17.0.x?
In "<Version>.0.x", the "x" part is variable based on the number of security updates within the period. Every time they release a security update in the main firefox tree during the period, they issue a new ".x" release in the ESR tree as well.
The length of "TIME" that the ESR tree exists is set, the "x" versions are not.
fred smith wrote:
Has anyone managed to get FF 18.0 to work on Centos 5.8?
I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
and dunno either what I've done wrong, or what other things need to be brought over.
Clues appreciated. :)
In case anyone is interested, I managed to rebuild firefox 18.0.1 on CentOS 5 (i686) without too many problems
It appears to run fine on CentOS 5
If anyone wants to know the details, then let me know
James Pearson
On Wed, Jan 23, 2013 at 02:15:21PM +0000, James Pearson wrote:
fred smith wrote:
Has anyone managed to get FF 18.0 to work on Centos 5.8?
I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
and dunno either what I've done wrong, or what other things need to be brought over.
Clues appreciated. :)
In case anyone is interested, I managed to rebuild firefox 18.0.1 on CentOS 5 (i686) without too many problems
It appears to run fine on CentOS 5
If anyone wants to know the details, then let me know
I've been thinking of trying to build it here, but haven't had time and energy, both at the same time, to try it. I have built firefox before, but not for several years, so it's probably changed since then.
But, yes, I'd like to see the gory details.
Thanks!
Fred
fred smith wrote:
In case anyone is interested, I managed to rebuild firefox 18.0.1 on CentOS 5 (i686) without too many problems
It appears to run fine on CentOS 5
If anyone wants to know the details, then let me know
I've been thinking of trying to build it here, but haven't had time and energy, both at the same time, to try it. I have built firefox before, but not for several years, so it's probably changed since then.
But, yes, I'd like to see the gory details.
Ok - this is what I did:
You need a more recent gcc/g++ - the latest gcc44 and g++44 that comes with CentOS 5 appears to work fine - so install these:
sudo yum install gcc44 g++44
You might need to install various other devel RPMS - the page at https://developer.mozilla.org/en/docs/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS gives an idea of what may be needed - the doc is for building 32 bit firefox on a fedora17 64 bit box - but gives some clues as to what else may be needed ...
The build process also needs python 2.6 - I happened to to have a local build of python 2.6, so I used that. But I believe python26 can be installed from other repos
Download and extract the firefox source from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0.1/source/firefox-18.0.1.source.tar.bz2
In the top level mozilla-release directory, create the file "mozconfig" containing something like:
. $topsrcdir/browser/config/mozconfig ac_add_options --enable-update-channel=release --enable-update-packaging --enable-official-branding --enable-stdcxx-compat --disable-gio mk_add_options MOZ_MAKE_FLAGS="-j4" export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1 CC="gcc44" CXX="g++44"
You may also need to add the line (something like):
PYTHON="python26"
i.e. the name/path of your python 2.6 binary
Note: the ac_add_options line is based on what is given via about:buildconfig when running a mozilla.org firefox 18 release - I removed the '--enable-warnings-as-errors' flag and added '--disable-gio' - as CentOS 5 doesn't have GIO support (???)
Then build by running:
make -f client.mk
Go and have a coffee or two
If all is OK, then do:
cd obj-i686-pc-linux-gnu make package
The bzip2'd tar archive will then be in the dist subdirectory
The above worked for me ...
James Pearson
On Wed, Jan 23, 2013 at 02:15:21PM +0000, James Pearson wrote:
fred smith wrote:
Has anyone managed to get FF 18.0 to work on Centos 5.8?
I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and glibc packages. now I"m getting:
./firefox: symbol lookup error: ./libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
and dunno either what I've done wrong, or what other things need to be brought over.
Clues appreciated. :)
In case anyone is interested, I managed to rebuild firefox 18.0.1 on CentOS 5 (i686) without too many problems
It appears to run fine on CentOS 5
If anyone wants to know the details, then let me know
James:
I gave it a quick try last night, and got hung up on the python version. The build wants <= 2.7, and EL5 has something much older than that.
I'd be afraid to just drop a new one in since thatwould probably break lots of things. Unless I could put it in a private place and just point the mozilla build to that location. Is that what you did?
Thanks!
Fred
fred smith wrote:
James:
I gave it a quick try last night, and got hung up on the python version. The build wants <= 2.7, and EL5 has something much older than that.
I'd be afraid to just drop a new one in since thatwould probably break lots of things. Unless I could put it in a private place and just point the mozilla build to that location. Is that what you did?
You can install a separate python 2.6 stack - e.g: http://pkgs.org/centos-5-rhel-5/epel-i386/python26-2.6.8-2.el5.i386.rpm.html
This won't interfere with the default CentOS 5 python 2.4 install
I think the firefox build process looks for a 'python2.6' binary - if not, then just add a line to your mozconfig like:
PYTHON=python2.6
I didn't do this, as I already had access to a locally rebuilt 2.6 install - but I guess the above should work, although I have no idea how much of the 2.6 stack will be required ...
James Pearson
You can install a separate python 2.6 stack - e.g: http://pkgs.org/centos-5-rhel-5/epel-i386/python26-2.6.8-2.el5.i386.rpm.html
This won't interfere with the default CentOS 5 python 2.4 install
I think the firefox build process looks for a 'python2.6' binary - if not, then just add a line to your mozconfig like:
PYTHON=python2.6
I didn't do this, as I already had access to a locally rebuilt 2.6 install - but I guess the above should work, although I have no idea how much of the 2.6 stack will be required ...
Thanks, James! The epel version of python26 works fine, and the only other package I needed was yasm from rpmforge. Build took <13m on a reasonable machine :)
lhecking@users.sourceforge.net wrote:
You can install a separate python 2.6 stack - e.g: http://pkgs.org/centos-5-rhel-5/epel-i386/python26-2.6.8-2.el5.i386.rpm.html
This won't interfere with the default CentOS 5 python 2.4 install
I think the firefox build process looks for a 'python2.6' binary - if not, then just add a line to your mozconfig like:
PYTHON=python2.6
I didn't do this, as I already had access to a locally rebuilt 2.6 install - but I guess the above should work, although I have no idea how much of the 2.6 stack will be required ...
Thanks, James! The epel version of python26 works fine, and the only other package I needed was yasm from rpmforge. Build took <13m on a reasonable machine :)
Yes, I forgot about yasm ... it needs > v1.0 - so the yasm from epel won't do
James Pearson
On Fri, Jan 25, 2013 at 11:32:57AM +0000, lhecking@users.sourceforge.net wrote:
You can install a separate python 2.6 stack - e.g: http://pkgs.org/centos-5-rhel-5/epel-i386/python26-2.6.8-2.el5.i386.rpm.html
This won't interfere with the default CentOS 5 python 2.4 install
I think the firefox build process looks for a 'python2.6' binary - if not, then just add a line to your mozconfig like:
PYTHON=python2.6
I didn't do this, as I already had access to a locally rebuilt 2.6 install - but I guess the above should work, although I have no idea how much of the 2.6 stack will be required ...
Thanks, James! The epel version of python26 works fine, and the only other package I needed was yasm from rpmforge. Build took <13m on a reasonable machine :)
the build process explicitly checks for python 2.7 or greater, so how does 2.6 succeed?
from the mach build tool:
#!/usr/bin/env python # This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/.
from __future__ import print_function, unicode_literals
import os import platform import sys
# Ensure we are running Python 2.7+. We put this check here so we generate a # user-friendly error message rather than a cryptic stack trace on module # import. if sys.version_info[0] == 2 and sys.version_info[1] < 7: print('Python 2.7 or above is required to run mach.') print('You are running', platform.python_version()) sys.exit(1)
fred smith wrote:
the build process explicitly checks for python 2.7 or greater, so how does 2.6 succeed?
from the mach build tool:
#!/usr/bin/env python # This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/.
from __future__ import print_function, unicode_literals
import os import platform import sys
# Ensure we are running Python 2.7+. We put this check here so we generate a # user-friendly error message rather than a cryptic stack trace on module # import. if sys.version_info[0] == 2 and sys.version_info[1] < 7: print('Python 2.7 or above is required to run mach.') print('You are running', platform.python_version()) sys.exit(1)
Are you sure that is used?
As a test, I did a fresh install of CentOS 5 i386, installed epel-release and rpmforge-release from http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm and http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
Then did:
yum groupinstall development-tools development-libs x-software-development gnome-software-development
yum install gcc44 gcc44-c++ python26 yasm-devel
Unpacked the firefox 18.0.1 source code, created the mozconfig file and ran 'make -f client.mk'
And it built fine ...
James Pearson
On Fri, Jan 25, 2013 at 02:03:17PM +0000, James Pearson wrote:
fred smith wrote:
the build process explicitly checks for python 2.7 or greater, so how does 2.6 succeed?
from the mach build tool:
#!/usr/bin/env python # This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/.
from __future__ import print_function, unicode_literals
import os import platform import sys
# Ensure we are running Python 2.7+. We put this check here so we generate a # user-friendly error message rather than a cryptic stack trace on module # import. if sys.version_info[0] == 2 and sys.version_info[1] < 7: print('Python 2.7 or above is required to run mach.') print('You are running', platform.python_version()) sys.exit(1)
Are you sure that is used?
It is if you follow Mozilla's build instructions, which are to build with "mach". I think that doing what you did will bypass mach. I tried it and got an error further into the build regarding some missing python stuff (but I haven't installed a newer python yet, so that's not unexpected.)
Is it also necessary to install the newer GCC that you used? I haven't yet noticed that listed in the build requirements...
As a test, I did a fresh install of CentOS 5 i386, installed epel-release and rpmforge-release from http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm and http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
Then did:
yum groupinstall development-tools development-libs x-software-development gnome-software-development
yum install gcc44 gcc44-c++ python26 yasm-devel
Unpacked the firefox 18.0.1 source code, created the mozconfig file and ran 'make -f client.mk'
fred smith wrote:
Are you sure that is used?
It is if you follow Mozilla's build instructions, which are to build with "mach". I think that doing what you did will bypass mach. I tried it and got an error further into the build regarding some missing python stuff (but I haven't installed a newer python yet, so that's not unexpected.)
Is it also necessary to install the newer GCC that you used? I haven't yet noticed that listed in the build requirements...
I initially tried it with the stock CentOS 5 gcc (v4.1.2 based) - but it failed - however, I noticed from about:buildconfig from a mozilla.org v18 install that they used a v4.5 based gcc, so I tried the nearest version available on CentOS 5 - which is from the gcc44 RPM - and that worked
James Pearson
On Fri, Jan 25, 2013 at 05:45:45PM +0000, James Pearson wrote:
fred smith wrote:
Are you sure that is used?
It is if you follow Mozilla's build instructions, which are to build with "mach". I think that doing what you did will bypass mach. I tried it and got an error further into the build regarding some missing python stuff (but I haven't installed a newer python yet, so that's not unexpected.)
Is it also necessary to install the newer GCC that you used? I haven't yet noticed that listed in the build requirements...
I initially tried it with the stock CentOS 5 gcc (v4.1.2 based) - but it failed - however, I noticed from about:buildconfig from a mozilla.org v18 install that they used a v4.5 based gcc, so I tried the nearest version available on CentOS 5 - which is from the gcc44 RPM - and that worked
ah. thanks for the tip.
Is it safe to assume that GCC44 installs and can be used separately from the one that comes with the system?
On Fri, Jan 25, 2013 at 02:58:45PM -0500, fred smith wrote:
On Fri, Jan 25, 2013 at 05:45:45PM +0000, James Pearson wrote:
fred smith wrote:
Are you sure that is used?
It is if you follow Mozilla's build instructions, which are to build with "mach". I think that doing what you did will bypass mach. I tried it and got an error further into the build regarding some missing python stuff (but I haven't installed a newer python yet, so that's not unexpected.)
Is it also necessary to install the newer GCC that you used? I haven't yet noticed that listed in the build requirements...
I initially tried it with the stock CentOS 5 gcc (v4.1.2 based) - but it failed - however, I noticed from about:buildconfig from a mozilla.org v18 install that they used a v4.5 based gcc, so I tried the nearest version available on CentOS 5 - which is from the gcc44 RPM - and that worked
ah. thanks for the tip.
OK, I've got all that installed. now when I run configure I get:
checking For gcc visibility bug with class-level attributes (GCC bug 26905)... no checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no checking for gcc PR49911... no checking for gcc pr39608... yes This compiler would fail to build firefox, plase upgrade.
Not sure I know how to make it use 4.4 instead of the older ones. (of course, it doesn't tell me which compiler it's trying to configure for, so maybe it is 4.4, I can't tell.)
In an effort to fix that I've done a series of exports:
# env | grep 44 gcc=gcc44 CC=gcc44 cc=gcc44 GXX=g++44
but it isn't helping. Can you divulge the correct incantation, please?
Gracias!
fred smith wrote:
OK, I've got all that installed. now when I run configure I get:
checking For gcc visibility bug with class-level attributes (GCC bug 26905)... no checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no checking for gcc PR49911... no checking for gcc pr39608... yes This compiler would fail to build firefox, plase upgrade.
Not sure I know how to make it use 4.4 instead of the older ones. (of course, it doesn't tell me which compiler it's trying to configure for, so maybe it is 4.4, I can't tell.)
In an effort to fix that I've done a series of exports:
# env | grep 44 gcc=gcc44 CC=gcc44 cc=gcc44 GXX=g++44
but it isn't helping. Can you divulge the correct incantation, please?
What does it say in the configure output for:
checking for gcc...
and:
checking compiler version...
Also, what is the contents of your mozconfig file (in the mozilla-release directory) - mine contains:
. $topsrcdir/browser/config/mozconfig ac_add_options --enable-update-channel=release --enable-update-packaging --enable-official-branding --enable-stdcxx-compat --disable-gio mk_add_options MOZ_MAKE_FLAGS="-j4" export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1 CC="gcc44" CXX="g++44"
James Pearson
P.S. The gcc44 install will not interfere with the default gcc install
On Fri, Jan 25, 2013 at 11:17:01PM +0000, James Pearson wrote:
fred smith wrote:
OK, I've got all that installed. now when I run configure I get:
checking For gcc visibility bug with class-level attributes (GCC bug 26905)... no checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no checking for gcc PR49911... no checking for gcc pr39608... yes This compiler would fail to build firefox, plase upgrade.
Not sure I know how to make it use 4.4 instead of the older ones. (of course, it doesn't tell me which compiler it's trying to configure for, so maybe it is 4.4, I can't tell.)
In an effort to fix that I've done a series of exports:
# env | grep 44 gcc=gcc44 CC=gcc44 cc=gcc44 GXX=g++44
but it isn't helping. Can you divulge the correct incantation, please?
What does it say in the configure output for:
checking for gcc...
and:
checking compiler version...
Also, what is the contents of your mozconfig file (in the mozilla-release directory) - mine contains:
. $topsrcdir/browser/config/mozconfig ac_add_options --enable-update-channel=release --enable-update-packaging --enable-official-branding --enable-stdcxx-compat --disable-gio mk_add_options MOZ_MAKE_FLAGS="-j4" export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1 CC="gcc44" CXX="g++44"
James:
OK, I got past that point by doing this:
CC=gcc44 gcc=gcc44 CXX=g++44 make -j 3 -f client.mk build
which runs for quite a while
it eventually ends with a bazillion lines about nothing to do for directory export, finally followed by some sort of error failure. I haven't figured out yet what that failure is.
Running it again, incorporating some of the stuff you've done in your mozconfig--but not all of it.
For example, I don't think you want it to be on the release update channel,... wouldn't that cause the firefox update logic to automatically clobber your build with the next automatic update? which resulting Firefox then won't work--the whole reason why we're doing our own builds.
[later...] Ah, it seems to have completed a build, now.
next dumb question: I recall from when I've built it (years) in the past that there's a tool, somewhere, for creating an installable .tgz file, like the one we can download from mozilla. so far I haven't tripped over it in 18.0.1, do you happen to know what that is?
thanks a bunch for all your guidance,I really appreciate it!
Fred
fred smith wrote:
For example, I don't think you want it to be on the release update channel,... wouldn't that cause the firefox update logic to automatically clobber your build with the next automatic update? which resulting Firefox then won't work--the whole reason why we're doing our own builds.
Good point - I was just copying what was given via about:buildconfig
In my case, this wouldn't matter as we lock the preferences "app.update.auto" and "app.update.enabled" to false to prevent automatic updates.
However, I don't know what a reasonable setting of 'enable-update-channel' should be instead?
[later...] Ah, it seems to have completed a build, now.
next dumb question: I recall from when I've built it (years) in the past that there's a tool, somewhere, for creating an installable .tgz file, like the one we can download from mozilla. so far I haven't tripped over it in 18.0.1, do you happen to know what that is?
Once 'make -f client.mk' has completed OK, cd to the obj-i686-pc-linux-gnu subdirectory and run 'make package' and it will create a bzip2'd tar archive in the dist subdirectory
James Pearson
On Sat, Jan 26, 2013 at 12:32:32PM +0000, James Pearson wrote:
fred smith wrote:
For example, I don't think you want it to be on the release update channel,... wouldn't that cause the firefox update logic to automatically clobber your build with the next automatic update? which resulting Firefox then won't work--the whole reason why we're doing our own builds.
Good point - I was just copying what was given via about:buildconfig
In my case, this wouldn't matter as we lock the preferences "app.update.auto" and "app.update.enabled" to false to prevent automatic updates.
However, I don't know what a reasonable setting of 'enable-update-channel' should be instead?
No, I don't know either. I left out that setting from my mozconfig, and when I fire up the new binary and choose "about firefox" it shows "default" update channel. Dunno what that means. I'll hafta do some snooping around on mozilla.org, I recall seeing a discussion of that there (somewhere) in the last year or two.
I seem to recall (vaguely) that there's also a file somewhere in the firefox data that contains a setting for that that should be changeable.
[later...] Ah, it seems to have completed a build, now.
next dumb question: I recall from when I've built it (years) in the past that there's a tool, somewhere, for creating an installable .tgz file, like the one we can download from mozilla. so far I haven't tripped over it in 18.0.1, do you happen to know what that is?
Once 'make -f client.mk' has completed OK, cd to the obj-i686-pc-linux-gnu subdirectory and run 'make package' and it will create a bzip2'd tar archive in the dist subdirectory
Oh, good, thanks! I've got it installed and so far (about 5 mins) it seems to be working fine.
thanks for putting up with my ignorance and long list of whines! :)
Fred
fred smith wrote:
However, I don't know what a reasonable setting of 'enable-update-channel' should be instead?
No, I don't know either. I left out that setting from my mozconfig, and when I fire up the new binary and choose "about firefox" it shows "default" update channel. Dunno what that means. I'll hafta do some snooping around on mozilla.org, I recall seeing a discussion of that there (somewhere) in the last year or two.
I guess it might be worth adding '--disable-updater' as well as leaving out '--enable-update-channel' ?
James Pearson
-
fred smith -
James Hogarth -
James Pearson -
John Doe -
Johnny Hughes -
lhecking＠users.sourceforge.net -
Theo Band