Summary: | app-office/libreoffice-3.4.3.2-r1 fails to compile with Error: symbol `Lcopy' is already defined | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jorge Nerin <jnerin> |
Component: | Current packages | Assignee: | Gentoo Office Team <office> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
partial build log of libreoffice-3.4.3.2-r1
Output of brigdes module manual build |
Description
Jorge Nerin
2011-09-16 08:16:25 UTC
Created attachment 286667 [details]
partial build log of libreoffice-3.4.3.2-r1
The build fails with error:
/var/tmp/portage/app-office/libreoffice-3.4.3.2-r1/work/libreoffice-bootstrap-3.4.3.2/bridges/source/cpp_uno/gcc3_linux_intel/uno2cpp.cxx:138: Error: symbol `Lcopy' is already defined
in line 6432.
Created attachment 286669 [details]
Output of brigdes module manual build
Manual build of bridges module following this instructions in the error output:
rm -Rf /var/tmp/portage/app-office/libreoffice-3.4.3.2-r1/work/libreoffice-bootstrap-3.4.3.2/bridges/unxlngi6.pro # optional module 'clean'
/bin/sh
cd /var/tmp/portage/app-office/libreoffice-3.4.3.2-r1/work/libreoffice-bootstrap-3.4.3.2
source ./LinuxX86Env.Set.sh
cd bridges
build
Please attach full build log, compressed if needed. Ignore my last comment ; you already did attach that file. Could you please try it with 3.4.4.2-r1? (not sure if it is fixed tbh, but I still fail to reproduce this bug in any way so i have no clue what is causing it) It still failed. For now I have just installed this way: emerge libreoffice # Fails but leaves work dir cd /var/tmp/portage/app-office/libreoffice-3.4.4.2-r1/work/libreoffice-bootstrap-3.4.4.2/bridges/source/cpp_uno/gcc3_linux_intel/ i686-pc-linux-gnu-gcc -c -o ../../../unxlngi6.pro/slo/call.o call.s # Repeat the failed compile command, this time works cd - ebuild /usr/portage/app-office/libreoffice/libreoffice-3.4.4.2-r1.ebuild compile ebuild /usr/portage/app-office/libreoffice/libreoffice-3.4.4.2-r1.ebuild install ebuild /usr/portage/app-office/libreoffice/libreoffice-3.4.4.2-r1.ebuild qmerge # I think compile & install are made automagically by qmerge if not fully made before. I did separatly just to be sure How about libreoffice-3.4.5 or libreoffice-3.5 ? (In reply to comment #7) > How about libreoffice-3.4.5 or libreoffice-3.5 ? No way, I tried again with app-office/libreoffice-3.5.0.3 and I have the same error, I have even done a emerge -e system ; emerge -e world before just to see if it was caused by some outdated file/package, but I still have the error. What I don't understand is what changes inside the build environment while inside of an emerge versus outside following the steps from the error. Following instructions from the error: # /bin/sh sh-4.1# cd /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3 sh-4.1# source ./Env.Host.sh sh-4.1# cd bridges sh-4.1# rm -Rf /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3/bridges/unxlngi6.pro # optional module 'clean' sh-4.1# build ============= (1/1) Building module bridges ============= [...] Entering /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3/bridges/source/cpp_uno/gcc3_linux_intel Compiling: bridges/unxlngi6.pro/misc/gcc3_uno_version.c Compiling: bridges/source/cpp_uno/gcc3_linux_intel/except.cxx Compiling: bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx Compiling: bridges/source/cpp_uno/gcc3_linux_intel/uno2cpp.cxx i686-pc-linux-gnu-gcc -c -o ../../../unxlngi6.pro/slo/call.o call.s touch ../../../unxlngi6.pro/slo/call.obj Making: libgcc3_uno.so Entering /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3/bridges/source/cpp_uno/gcc3_solaris_intel [...] sh-4.1# The output from the error: Entering /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3 .5.0.3/bridges/source/cpp_uno/gcc3_linux_intel Compiling: bridges/unxlngi6.pro/misc/gcc3_uno_version.c Compiling: bridges/source/cpp_uno/gcc3_linux_intel/except.cxx Compiling: bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx Compiling: bridges/source/cpp_uno/gcc3_linux_intel/uno2cpp.cxx i686-pc-linux-gnu-gcc -c -o ../../../unxlngi6.pro/slo/call.o call.s /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3/br idges/source/cpp_uno/gcc3_linux_intel/uno2cpp.cxx: Assembler messages: /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3/bridges/source/cpp_uno/gcc3_linux_intel/uno2cpp.cxx:136: Error: symbol `Lcopy' is already defined dmake: Error code 1, while making '../../../unxlngi6.pro/slo/uno2cpp.obj' This system is very old (beginning of 2006), is a 32bit system running in a 64bit processor, maybe I have and outdated file or library lying around. Or perhaps I should upgrade to 64bit and start over, but first I would like to find the root cause of this error, and second I have to find the time to do the jump. Could you please attach once more your current emerge --info and /etc/make.conf (In reply to comment #9) > Could you please attach once more your current emerge --info and > /etc/make.conf Your suggestion to reattach it make me think about CFLAGS, investigating a little I found that for example in libreoffice 3.3.0 (http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-office/libreoffice/libreoffice-3.3.0_rc4.ebuild?hideattic=0&diff_format=s&revision=1.3&view=markup the first I found about) we have something like that: 348 # Compile problems with these ... 349 filter-flags "-funroll-loops" 350 filter-flags "-fprefetch-loop-arrays" 351 filter-flags "-fno-default-inline" 352 filter-flags "-ftracer" 353 filter-flags "-fforce-addr" 354 355 filter-flags "-O[s2-9]" 356 357 if [[ $(gcc-major-version) -lt 4 ]]; then 358 filter-flags "-fstack-protector" 359 filter-flags "-fstack-protector-all" 360 replace-flags "-fomit-frame-pointer" "-momit-leaf-frame-pointer" 361 fi Now we don't filter out anything (libreoffice-3.5.0.3.ebuild): src_prepare() { # optimization flags export ARCH_FLAGS="${CXXFLAGS}" export LINKFLAGSOPTIMIZE="${LDFLAGS}" So I tested a change in make.conf from: CFLAGS="-O2 -march=native -mfpmath=sse -ftracer -pipe" to: CFLAGS="-O2 -march=native -pipe" And even though it hasn't finished compiling it has already surpassed the problematic point (from the current log): Entering /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3 .5.0.3/bridges/source/cpp_uno/gcc3_linux_intel Compiling: bridges/unxlngi6.pro/misc/gcc3_uno_version.c Compiling: bridges/source/cpp_uno/gcc3_linux_intel/except.cxx Compiling: bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx Compiling: bridges/source/cpp_uno/gcc3_linux_intel/uno2cpp.cxx i686-pc-linux-gnu-gcc -c -o ../../../unxlngi6.pro/slo/call.o call.s touch ../../../unxlngi6.pro/slo/call.obj Making: libgcc3_uno.so Entering /var/tmp/portage/app-office/libreoffice-3.5.0.3/work/libreoffice-core-3.5.0.3/bridges/source/cpp_uno/gcc3_solaris_intel I will report the success after testing it. Perhaps we should filter out some flags again. As it may be pertinent I should note again that this is a 32bit system running in an 64bit AMD Athlon(tm) 64 X2 Dual Core Processor 3800+. I found an old bug about ftracer in gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025 (v4.3.3, 4.4.1, etc -ftracer sometimes fails by "is already defined"), I now have gcc (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) 4.5.3 Well it is the problem, it should not fail with various clfags, it is tested a lot to work with common ones (even ricer funroll-loops and others) but I won't strip cflag options just because they are broken. It should be more for the user to fix his install :) Btw if you decide to migrate your machine to amd64 be sure to give try to hardened flavor instead of normal gentoo. (In reply to comment #11) > Well it is the problem, it should not fail with various clfags, it is tested > a lot to work with common ones (even ricer funroll-loops and others) but I > won't strip cflag options just because they are broken. It should be more > for the user to fix his install :) > > Btw if you decide to migrate your machine to amd64 be sure to give try to > hardened flavor instead of normal gentoo. Ok, I understand your point, it seems to be a longstanding bug in gcc's ftracer algorithm, but at least there could be a warning about having it enabled, it's giving problems with asm labels since 2003 (http://lists.gforge.info.ucl.ac.be/pipermail/mozart-hackers/2003/001164.html). I forgot to close it, it was a bug in the ftracer flag of gcc that I had added to CFLAGS. |