Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved] Firefox and Seamonkey: internal compiler error
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Tue Apr 30, 2013 10:17 pm    Post subject: [solved] Firefox and Seamonkey: internal compiler error Reply with quote

Hi there,

I'm using 2 computers:
  • Atom N270 Notebook
  • Xeon X5650 Workstation


I'm building big packages for my Atom notebook on my Xeon machine within a chroot environment. The Atom has the movbe instruction, which the Xeon doesn't understand. So I disabled that instruction for all concerning packages.

The last system-update had been done quite a long time ago. As I remember, everything worked fine. But this time I can't compile neither firefox nor seamonkey. The fail with the following error:

emerge firefox:
i686-pc-linux-gnu-g++ -o Stack.o -c  -I./../../dist/system_wrappers_js -include /var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/config/gcc_hidden.h -DENABLE_TYPEDARRAY_MOVE -DENABLE_YARR_JIT=1 -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".so\" -DUSE_ZLIB -I/usr/lib/libffi-3.0.13/include  -I.  -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/../../mfbt/double-conversion -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src -I. -I./../../dist/include  -I/usr/include/nspr      -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/assembler -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/yarr  -fPIC  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=atom -O2 -fomit-frame-pointer -pipe -mno-movbe -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe  -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1   -DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/Stack.o.pp  /var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/vm/Stack.cpp
String.cpp
/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/vm/Stack.cpp: In member function 'js::StackIter& js::StackIter::operator++()':
/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/vm/Stack.cpp:1593:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
make[5]: *** [Stack.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory `/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/obj-i686-pc-linux-gnu/js/src'
make[4]: *** [libs_tier_js] Error 2
make[4]: Leaving directory `/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[3]: *** [tier_js] Error 2
make[3]: Leaving directory `/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory `/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release'
make: *** [build] Error 2
emake failed
 * ERROR: www-client/firefox-20.0.1 failed (compile phase):
 *   emake failed


In the logfile on the Xeon machine I get additionally:
/var/log/messages:
Apr 30 23:12:26 localhost kernel: [88133.324951] traps: ld[10344] trap invalid opcode ip:807ab50 sp:fff6569c error:0 in ld[8048000+cb000]
Apr 30 23:12:54 localhost kernel: [88161.366376] traps: ld[15712] trap invalid opcode ip:807ab50 sp:ffe47ccc error:0 in ld[8048000+cb000]
Apr 30 23:45:19 localhost kernel: [90100.718437] traps: ld[13157] trap invalid opcode ip:807ab50 sp:ffcff36c error:0 in ld[8048000+cb000]
Apr 30 23:45:46 localhost kernel: [90128.178787] traps: ld[18533] trap invalid opcode ip:807ab50 sp:fffe43dc error:0 in ld[8048000+cb000]
Apr 30 23:49:04 localhost kernel: [90325.862259] traps: ld[24334] trap invalid opcode ip:807ab50 sp:ffa0c8ac error:0 in ld[8048000+cb000]
Apr 30 23:49:31 localhost kernel: [90352.855015] traps: ld[29652] trap invalid opcode ip:807ab50 sp:ffa98e9c error:0 in ld[8048000+cb000]


What's wrong here?


Last edited by musv on Fri May 03, 2013 8:21 am; edited 1 time in total
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Wed May 01, 2013 2:25 am    Post subject: Reply with quote

This happens in the chroot?
Apparently that ld has some instruction the compiling machine doesn't understand, you may want to try rebuilding binutils with xeon instructions to see if it will go away (and hope itself won't crash during build). Since you're not building with the atom anyway, it's not like it will affect it that much...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?


Last edited by eccerr0r on Wed May 01, 2013 2:29 am; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2222
Location: UK

PostPosted: Wed May 01, 2013 2:29 am    Post subject: Reply with quote

"invalid opcode" points to using CFLAGS in the build system the host can't handle.

You might want to look into the emerge --root= option instead of an entire chroot, if you do all the building on the Xeon anyway.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Wed May 01, 2013 10:24 am    Post subject: Reply with quote

eccerr0r wrote:
This happens in the chroot?
Apparently that ld has some instruction the compiling machine doesn't understand, you may want to try rebuilding binutils with xeon instructions to see if it will go away

Yes, this happens in the chroot. On the Notebook I don't wan't to build Seamonkey as it would take a lot of hours to build. Furthermore the RAM on that machine isn't enough.

I rebuilt the binutils without movbe, but the error didn't go away. It's strange, Firefox and Seamonkey are the only problematic packages.

Ant P. wrote:
"invalid opcode" points to using CFLAGS in the build system the host can't handle.

As I have checked, movbe is the only command the Atom CPU has, which den Xeon doesn't understand.

Ant P. wrote:
You might want to look into the emerge --root= option instead of an entire chroot, if you do all the building on the Xeon anyway.

You mean a Cross-Compile-Environment? I failed with this idea last year. According to my thread there, I haven't found anyone, who set up a fully working cross-compile environment. So at least to update my Atom Notebook, the best idea is the chroot environment.

Additionally I tried MAKEOPTS="-j1". Didn't help too.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Wed May 01, 2013 11:25 am    Post subject: Reply with quote

I've got another suspicion:

As a part of the system-update, I upgraded gcc from 4.6.2 to 4.7.2.

I rebuilt libtool, binutils, glib, glibc. But that didn't help anything.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Wed May 01, 2013 12:40 pm    Post subject: Reply with quote

ok, the next step.

I ran locally on my Atom Notebook:
Code:
emerge -1 eigen


That fails too:
Code:
Scanning dependencies of target example_MatrixSine
make[3]: Leaving directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
make -f unsupported/doc/examples/CMakeFiles/example_MatrixSine.dir/build.make unsupported/doc/examples/CMakeFiles/example_MatrixSine.dir/build
make[3]: Entering directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
/usr/bin/cmake -E cmake_progress_report /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/CMakeFiles 48
[100%] Building CXX object unsupported/doc/examples/CMakeFiles/example_MatrixSine.dir/MatrixSine.cpp.o
cd /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples && /usr/bin/i686-pc-linux-gnu-g++  -DEIGEN_PERMANENTLY_DISABLE_STUPID_WARNINGS  -march=atom -O2 -fomit-frame-pointer -pipe  -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fexceptions -fno-check-new -fno-common -fstrict-aliasing -Wno-variadic-macros -Wextra -pedantic  -g2 -g0 -O2  -fno-inline-functions -I/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples -I/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/doc/examples -I/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3 -I/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build -I/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/doc/examples/../../../unsupported -I/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/doc/examples/../../../unsupported/test    -o CMakeFiles/example_MatrixSine.dir/MatrixSine.cpp.o -c /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/doc/examples/MatrixSine.cpp
In file included from /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/Eigen/MatrixFunctions:57:0,
                 from /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/doc/examples/MatrixSine.cpp:1:
/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/Eigen/src/MatrixFunctions/MatrixFunction.h: In Elementfunktion »Eigen::MatrixFunction<MatrixType, AtomicType, 1>::DynMatrixType Eigen::MatrixFunction<MatrixType, AtomicType, 1>::solveTriangularSylvester(const DynMatrixType&, const DynMatrixType&, const DynMatrixType&) [with MatrixType = Eigen::Matrix<std::complex<double>, -1, -1>; AtomicType = Eigen::MatrixFunctionAtomic<Eigen::Matrix<std::complex<double>, -1, -1> >; Eigen::MatrixFunction<MatrixType, AtomicType, 1>::DynMatrixType = Eigen::Matrix<std::complex<double>, -1, -1>; typename MatrixType::Scalar = std::complex<double>]«:
/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3/unsupported/Eigen/src/MatrixFunctions/MatrixFunction.h:432:65: interner Compiler-Fehler: Speicherzugriffsfehler
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Fehler in der deutschen Übersetzung sind an translation-team-de@lists.sourceforge.net zu melden.

Gehen Sie gemäß den Hinweisen in <http://bugs.gentoo.org/> vor.
make[3]: *** [unsupported/doc/examples/CMakeFiles/example_MatrixSine.dir/MatrixSine.cpp.o] Fehler 1
make[3]: Leaving directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
make[2]: *** [unsupported/doc/examples/CMakeFiles/example_MatrixSine.dir/all] Fehler 2
make[2]: *** Warte auf noch nicht beendete Prozesse...
Linking CXX executable example_MatrixSquareRoot
cd /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples && /usr/bin/cmake -E cmake_link_script CMakeFiles/example_MatrixSquareRoot.dir/link.txt --verbose=1
/usr/bin/i686-pc-linux-gnu-g++   -march=atom -O2 -fomit-frame-pointer -pipe  -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fexceptions -fno-check-new -fno-common -fstrict-aliasing -Wno-variadic-macros -Wextra -pedantic  -g2 -g0 -O2  -fno-inline-functions   -Wl,-O1 -Wl,--as-needed CMakeFiles/example_MatrixSquareRoot.dir/MatrixSquareRoot.cpp.o  -o example_MatrixSquareRoot -rdynamic
cd /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples && ./example_MatrixSquareRoot >/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples/MatrixSquareRoot.out
make[3]: Leaving directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
/usr/bin/cmake -E cmake_progress_report /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/CMakeFiles
[100%] Built target example_MatrixSquareRoot
Linking CXX executable example_PolynomialSolver1
cd /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples && /usr/bin/cmake -E cmake_link_script CMakeFiles/example_PolynomialSolver1.dir/link.txt --verbose=1
/usr/bin/i686-pc-linux-gnu-g++   -march=atom -O2 -fomit-frame-pointer -pipe  -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -fexceptions -fno-check-new -fno-common -fstrict-aliasing -Wno-variadic-macros -Wextra -pedantic  -g2 -g0 -O2  -fno-inline-functions   -Wl,-O1 -Wl,--as-needed CMakeFiles/example_PolynomialSolver1.dir/PolynomialSolver1.cpp.o  -o example_PolynomialSolver1 -rdynamic
cd /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples && ./example_PolynomialSolver1 >/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/unsupported/doc/examples/PolynomialSolver1.out
make[3]: Leaving directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
/usr/bin/cmake -E cmake_progress_report /var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build/CMakeFiles
[100%] Built target example_PolynomialSolver1
make[2]: Leaving directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
make[1]: *** [doc/CMakeFiles/doc.dir/rule] Fehler 2
make[1]: Leaving directory `/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
make: *** [doc] Fehler 2
 * ERROR: dev-cpp/eigen-3.1.3 failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=dev-cpp/eigen-3.1.3'`,
 * the complete build log and the output of `emerge -pqv '=dev-cpp/eigen-3.1.3'`.
 * The complete build log is located at '/var/tmp/portage/dev-cpp/eigen-3.1.3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-cpp/eigen-3.1.3/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3_build'
 * S: '/var/tmp/portage/dev-cpp/eigen-3.1.3/work/eigen-3.1.3'

>>> Failed to emerge dev-cpp/eigen-3.1.3, Log file:

-> MatrixFunctions/MatrixFunction.h:432:65: interner Compiler-Fehler: Speicherzugriffsfehler = internal compiler error: segmentation fault

This brings me to the point, that something has gone wrong on my system.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Wed May 01, 2013 2:44 pm    Post subject: Reply with quote

Yes, segfaults are usually hardware problems with gcc. but invalid instruction can also be hardware issues - if your ram/motherboard/cpu is corrupting instruction memory you'll get invalid instructions, but if corruption occurs in data memory, you'll tend to get segmentation faults or silent data corruption.

That is not to say gcc code writers are perfect coders and never write code with bugs... but unlikely...

(Incidentally, I make my Atom N270 netbook compile for itself (it runs Gentoo) but using other machines on the network for distcc. Other than disk space issues, it's not horribly bad. Then again I have 2GB RAM in this machine.)
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Wed May 01, 2013 7:35 pm    Post subject: Reply with quote

Ok, to ensure, if it's really related to my chroot-environment, I tried to compile Firefox via distcc only on the Atom:

Code:
/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/vm/Stack.cpp: In member function 'js::StackIter& js::StackIter::operator++()':
/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/vm/Stack.cpp:1593:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive

I'm not sure where to search the error anymore.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Wed May 01, 2013 7:40 pm    Post subject: Reply with quote

I'd say your Xeon may be having problems. If the Xeon is having segfault problems with the chroot, likely it will also have problems with distcc. If you ran without distcc on the Atom, perhaps the outcome would be different?

Does the Xeon compile its own stuff fine still? Are you using the same gcc for both machines?
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Thu May 02, 2013 9:00 am    Post subject: Reply with quote

eccerr0r wrote:
Does the Xeon compile its own stuff fine still? Are you using the same gcc for both machines?

Yes, the Xeon compiles without any problem. No segfaults, no errors.

I'm using on both machines gcc-4.7.2.

Due to the segfault (without distcc) of dev-cpp/eigen on the Atom, I would say, something is wrong on that machine. To recapitulate:
  • I'm compiling in a chroot. Means I mount via nfs the root directory from the Atom on the Xeon. Temp directories, Distfiles and Portage are used from the Xeon.
  • Building Firefox and Seamonkey on the Xeon fails.
  • Building Firefox and Seamonkey on the Atom using distcc fails too.
  • Building dev-cpp/eigen fails on both in the chroot on the Xeon and without distcc on the Atom


Conclusion:
  • At least there shouldn't be any hardware defects of the RAM, because eigen fails on both machines.
  • The SSD, which contains the whole system on the SSD has been checked and should be ok too.
  • The previous update more than half a year ago worked that way. The difference are the versions of the system packages, e.g. gcc-4.6 instead of gcc-4.7
  • Xeon is running 64bit, Atom: 32bit.


An idea would be to downgrade the gcc to 4.6. Do I have to downgrade anything else?

Btw. I found that thread. Unfortunately they didn't write if the found any solution.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Thu May 02, 2013 9:20 pm    Post subject: Reply with quote

I've got my toolchain, firefox, etc. all compiled just fine with gcc-4.6.3 with CFLAGS="-O2 -mtune=i686 -pipe".

It may well be that gcc-4.7.2 and its corresponding binutils that's broken, that's why it's marked unstable/testing. I don't know if there are any special CFLAGS being used, but this also tends to stress the compilers, possibly differently with different versions.

The compiler on the Xeon should be just fine emitting movbe instructions from the assembler, as long as it does not have to execute them...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Fri May 03, 2013 8:20 am    Post subject: Reply with quote

eccerr0r wrote:
The compiler on the Xeon should be just fine emitting movbe instructions from the assembler, as long as it does not have to execute them...

That was the reason, why I removed movbe from several packages via portage/env. E.g. update-icon-cache always failed at the end of the build process with an invalid instruction. But that's a solved problem.

Update:
I downgraded gcc to 4.6.4 and both Seamonkey and Firefox are building fine. So it's definitely a problem with gcc-4.7.x on i686.

Is that now a bug of gcc or the Mozilla stuff?
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Fri May 03, 2013 1:14 pm    Post subject: Reply with quote

I was just pointing out: this seems to be wrong though it's not the problem at hand:

From your first post:

i686-pc-linux-gnu-g++ -o Stack.o -c -I./../../dist/system_wrappers_js -include /var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/config/gcc_hidden.h -DENABLE_TYPEDARRAY_MOVE -DENABLE_YARR_JIT=1 -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".so\" -DUSE_ZLIB -I/usr/lib/libffi-3.0.13/include -I. -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/../../mfbt/double-conversion -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src -I. -I./../../dist/include -I/usr/include/nspr -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/assembler -I/var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/yarr -fPIC -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=atom -O2 -fomit-frame-pointer -pipe -mno-movbe -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1 -DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/Stack.o.pp /var/tmp/portage/www-client/firefox-20.0.1/work/mozilla-release/js/src/vm/Stack.cpp

A bit contradictory I think... I would think either there's a problem the ebuild/makefile or something setup weird with your make.conf...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Fri May 03, 2013 1:21 pm    Post subject: Reply with quote

Code:
-march=atom -mno-movbe

is correct.

In CFLAGS in make.conf I've set only:
Code:
-march=atom


movbe is an Atom-only instruction. So it isn't understood by the Xeon. That's not a problem, when I compile packages on the Xeon via chroot for the Atom. But it becomes a problem, if in the built package is a tool included, which uses the movbe instruction e.g. in the install-routine. An example would be update-mime-info.

Therefore I created:
/etc/portage/env/nomovbe:
CFLAGS="-mno-movbe"

and linked problematic packages to that file to overwrite the CFLAGS. I had to do that for Kdelibs, Seamonkey, Firefox, Binutils and a few others.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Fri May 03, 2013 5:16 pm    Post subject: Reply with quote

Yes that's annoying that tools built by the packages themselves are using special instructions. That's why I tried to opt for using distcc whenever I can, which should avoid the problem and still use the special instructions tailored each individual CPU... except...

why I mostly just use -mtune=i686 nowadays. I got fed up with it when I had an emergency/temporary disk move when my athlonxp server's disk died. I put my p4's disk on it that was tuned for sse2, which ended up in more grief since now I had to rebuild the system while waiting to get a new disk (downtime). I would have to rebuild again when moving it back to the p4 if I didn't switch to i686...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Fri May 03, 2013 7:14 pm    Post subject: Reply with quote

eccerr0r wrote:
That's why I tried to opt for using distcc whenever I can

Distcc has some major disadvantages for me compared to the chroot:
  • My Xeon has 24 GB Ram, the Atom 2 GB. On the Xeon I can build every package in the RAM without touching the SSD.
  • While chroot uses up to 100% CPU consumption, distcc is mostly at 20% at the Xeon.
  • sending and receiving data packages in distcc mode takes also quite a bit of time, which you don't have in the chroot.

So distcc is only suitable for smaller packages.

I guess, even a x86 virtual environment (qemu_user or qemu) would be faster than a distcc only solution.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Fri May 03, 2013 9:32 pm    Post subject: Reply with quote

So you're actually physically transferring the disk over to do updates? I heard that NFS does not work for portage, wonder if there are any other network filesystems that do. Or how *are* you getting the images back and forth? Hopefully not rsync *shiver* ...

Really I'm lazy and the machines can go and build while I do something else, and it's still faster than local only when I use distcc for the most part (only exception is the linker phase in firefox because distcc cannot remote link). Distcc over wifi is pretty bad too, it is too slow and its latency bad - you have to use wired ethernet, preferably Gbit with small frames. 100Mbit is marginal but that's all I have on my Atom, and I have to make sure it's hooked. But yes my atom also has a disk problem which I end up just hooking up a USB HDD for just building firefox, pretty much all the other packages build just fine in 2GB RAM building in tmpfs.

I've found that qemu is pretty slow, but maybe not too bad (my test environment was the Maemo SDK/ubuntu-32 bit and running some contrived benchmark). On my Core2 Duo it about halves the speed (using KVM and VMX; it's unusable without VMX). I heard Virtualbox is better but I haven't tried it.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Sat May 04, 2013 7:20 am    Post subject: Reply with quote

eccerr0r wrote:
So you're actually physically transferring the disk over to do updates?

No, I'm using nfs. I wrote a little script to mount the needed stuff on the Xeon:
minimount:

#!/bin/sh

mount /mnt/miniding
mount -o bind /proc /mnt/miniding/proc
mount -o bind /dev /mnt/miniding/dev
mount -o bind /dev/pts /mnt/miniding/dev/pts
mount -o bind /usr/portage /mnt/miniding/usr/portage
mount -o bind /var/portage/distfiles /mnt/miniding/var/portage/distfiles
mount -t tmpfs tmpfs /mnt/miniding/var/tmp/portage
chroot /mnt/miniding /bin/bash

After that I set:
Code:
setarch i686


The nfs export of the Atom:
/etc/exports:
/export/root            192.168.109.0/24(rw,fsid=1,nohide,insecure,no_subtree_check,async,no_root_squash)

/ is mounted to /export/root. It's the nfs4 syntax, which is quite strange.

That's all. I mount the root-Device from the Atom, take the Portage and the temp dirs from the Xeon and just compile.

eccerr0r wrote:
I've found that qemu is pretty slow, but maybe not too bad

You have to decide between qemu and qemu-user. Should be faster, but I haven't tried it until now.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2545
Location: de

PostPosted: Tue May 14, 2013 7:46 am    Post subject: Reply with quote

Just to provide more information:

The problem is described in Bug #461694.
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 3601
Location: USA

PostPosted: Tue May 14, 2013 1:56 pm    Post subject: Reply with quote

Heh. Another reason never to write cute code:

patch wrote:

Code:
> -  *o = ALLOCNO_OBJECT (a, i->n);
> -  return i->n++ < ALLOCNO_NUM_OBJECTS (a);
> +  int n = i->n++;
> +  if (n < ALLOCNO_NUM_OBJECTS (a))
> +    {
> +      *o = ALLOCNO_OBJECT (a, n);
> +      return true;
> +    }
> +  return false;


I don't think I'd ever write something like i->n++<ALLOC_NUM_OBJECTS(a) ... that's just asking for problems...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum