Closed Bug 949091 Opened 11 years ago Closed 7 years ago

B2G Emulator: Duplicate symbol / dylib1.o linking errors in Mac OS X when building

Categories

(Firefox OS Graveyard :: Emulator, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: marshall, Assigned: marshall)

Details

Attachments

(2 files)

When compiling the 'emulator' config with Xcode 5.0.1 in OS X 10.8.5, I saw this linking error when trying to build: host Executable: triangleCM (out/host/darwin-x86/obj/EXECUTABLES/triangleCM_intermediates/triangleCM) duplicate symbol __dyld_func_lookup in: /usr/lib/crt1.10.5.o /usr/lib/dylib1.o duplicate symbol dyld_stub_binding_helper in: /usr/lib/crt1.10.5.o /usr/lib/dylib1.o ld: 2 duplicate symbols for architecture i386 collect2: ld returned 1 exit status make: *** [out/host/darwin-x86/obj/EXECUTABLES/triangleCM_intermediates/triangleCM] Error 1 I setup my environment with the Mac bootstrap script in the B2G repo.
Attached file Mac emulator GL test link fixes (deleted) —
Attachment #8346118 - Flags: review?(mwu)
Thanks Marshall! We noticed we don't hit this issue is we use the xcode/command line tools gcc-llvm compiler for c++ code, but if we have a gnu gcc compiler that with c++ compilation enabled, and use this for compiling the c++ code, we do hit this issue. So it looks like something that our gcc-llvm compiler overlooks/forgives the code, where our current gnu gcc compiler gets blocked and this error occurs. GNU-GCC compiler (that hits this error while compiling): ======================================================== [cltbld@bld-lion-r5-087.build.releng.scl3.mozilla.com ~]$ /usr/local/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc-4.6/4.6.3/gcc/libexec/gcc/x86_64-apple-darwin11.2.0/4.6.3/lto-wrapper Target: x86_64-apple-darwin11.2.0 Configured with: ../configure --enable-languages=c,c++ --prefix=/usr/local/Cellar/gcc-4.6/4.6.3/gcc --datarootdir=/usr/local/Cellar/gcc-4.6/4.6.3/share --bindir=/usr/local/Cellar/gcc-4.6/4.6.3/bin --program-suffix=-4.6 --with-gmp=/usr/local/Cellar/gmp/5.1.3 --with-mpfr=/usr/local/Cellar/mpfr/3.1.2 --with-mpc=/usr/local/Cellar/libmpc/1.0.1 --with-system-zlib --enable-stage1-checking --enable-plugin --enable-lto --disable-nls Thread model: posix gcc version 4.6.3 (GCC) GCC-LLVM (Apple) compiler (that does not his this problem): =========================================================== [cltbld@bld-lion-r5-087.build.releng.scl3.mozilla.com ~]$ /usr/bin/gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) [cltbld@bld-lion-r5-087.build.releng.scl3.mozilla.com ~]$ In order to demonstrate this behaviour, we set our PATH to include /usr/local/bin/g++ and /usr/local/bin/c++ and we get this error. Without making any other changes, we can then change the PATH to pick up /usr/local/bin/c++ and /usr/local/bin/g++, and then this problem goes away. Therefore it may also be the case that this problem can be solved by either: 1) switching compiler or 2) changing compiler settings and rebuilding compiler. For this reason I've included the configure settings of both compilers, which might give some insight into the reason it compiles on one and not the other. Of course the two compilers will no doubt come from diverged source trees, so it might also be the case that the gnu compiler simply can't compile this c++ code regardless of the configure settings used when compiling the compiler! I wanted to raise this, since it sounds like you have the same error as us, but the circumstances are a little bit different (since we hit it when using a custom compiler rather than the xcode/command line tools compiler). Lastly I wanted to ask if you see any issues with us using the gnu gcc compiler for the c++ code. By default with the regular setup, this is not enabled. In order to get this working, we had to enable multilibs, since by default multilibs is disabled (see https://github.com/mozilla-b2g/B2G/blob/master/scripts/homebrew/gcc-4.6.rb#L117) - by removing this line, we enabled the multilib builds. We also had to enable c++ compiler in gcc by changing the call in bootstrap-mac.sh that brew installs from https://github.com/mozilla-b2g/B2G/blob/master/scripts/homebrew/gcc-4.6.rb (see https://github.com/mozilla-b2g/B2G/blob/05b336020a7df015dcea453d8c52dc77f458a7f1/scripts/bootstrap-mac.sh#L163) to use --enable-cxx in the brew install command (see https://github.com/mozilla-b2g/B2G/blob/master/scripts/homebrew/gcc-4.6.rb#L7-L9). In other words, as I see it, if a developer follows the regular machine setup guide, he will build a custom gcc compiler that compiles *only* c code, and that c++ code would get compiled by his/her native apple xcode/command line tools compiler, due to the links I've highlighted above. My guess is that this is an oversight, and that if we can demonstrate everything can be done using the gnu gcc compiler, probably we can remove the requirement to have an xcode/command line tools installation on the system at all. Do you agree with this assessment? Many thanks! Pete
Flags: needinfo?(marshall)
(In reply to Pete Moore [:pete][:pmoore] from comment #2) > In other words, as I see it, if a developer follows the regular machine > setup guide, he will build a custom gcc compiler that compiles *only* c > code, and that c++ code would get compiled by his/her native apple > xcode/command line tools compiler, due to the links I've highlighted above. > My guess is that this is an oversight, and that if we can demonstrate > everything can be done using the gnu gcc compiler, probably we can remove > the requirement to have an xcode/command line tools installation on the > system at all. Do you agree with this assessment? I don't think this was an oversight as much as a failure to find out why the brew g++-4.6 failed to build, while the system llvm-g++ works just fine (i.e. if it ain't broke, don't fix it :). Did you run into any Obj-C++ build errors when building the emulator with your custom version of g++-4.6? IIRC the non-Apple toolchains have issues linking against some of the system Obj-C frameworks and using some custom dylib linking tricks. Part of this is also a discussion about how far we want to diverge from AOSP. For example, in AOSP master right now, the requirement for building is Mac OS X 10.8 and Xcode 4.5.2. We've already strayed from this path quite a bit to get to this state, but if we forego Xcode altogether I see things getting more complicated for us as we move to newer versions of AOSP (i.e. jellybean).
Flags: needinfo?(marshall)
Marshall, do you also see this problem on emulator-jb?
Flags: needinfo?(marshall)
Attached file Build log (deleted) —
Hi Marshall, Using the g++ compiler exclusively, built with the options mentioned by Pete to support c++ compilation and to enable multilibs, the build procedure completes, but actually there are some error messages being raised while verifying the linker, e.g.: 10:47:31 ERROR - checking whether the linker supports Identical Code Folding... /Users/cltbld/b2g_build/build-dir/build/gecko/configure: line 9911: objdump: command not found Please let us know whether you can find something (else) "suspicious" in this log file, which may be related to the compiler being used.
(In reply to Michael Wu [:mwu] from comment #4) > Marshall, do you also see this problem on emulator-jb? I haven't been able to get a successful build of emulator-jb yet. I'm seeing a ton of compiler errors in my environment.. http://pastebin.mozilla.org/3798597 This looks like an issue with finding the system SDKs..
Flags: needinfo?(marshall)
Comment on attachment 8346118 [details] Mac emulator GL test link fixes I think this is an ICS only fix, so we can just land it.
Attachment #8346118 - Flags: review?(mwu) → review+
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: