Closed
Bug 292266
Opened 19 years ago
Closed 19 years ago
Unable to build Firefox on Tiger due to MoreFilesX conflict with system header
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 292530
People
(Reporter: krmathis, Unassigned)
References
Details
Attachments
(1 file)
3.15 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050422 Firefox/1.0+ (PowerBook) Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050422 Firefox/1.0+ (PowerBook) I am unable to compile Firefox from Trunk with GCC 4.0 (Mac OS 10.4 with Xcode 2.0). Using the example .mozconfig from: http://www.mozilla.org/build/configure-build.html -------------------------- . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/fb-opt-static ac_add_options --enable-optimize ac_add_options --disable-debug ac_add_options --enable-static ac_add_options --disable-shared ac_add_options --disable-tests -------------------------- Reproducible: Always Steps to Reproduce: 1. Use the above mentioned .mozconfig file 2. Pull and build the latest Trunk source Actual Results: Compile process errors out Expected Results: Compile process completes successfully Error: -------------------------- gcc -o MoreFilesX.o -c -DOSTYPE=\"Darwin8.0.0\" -DOSARCH=\"Darwin\" -DBUILD_ID=0000000000 -I../../dist/include/macmorefiles -I../../dist/include -I../../dist/include/nspr -I../../dist/sdk/include -I/usr/X11R6/include -fPIC -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -fpascal-strings -no-cpp-precomp -fno-common -I/Developer/Headers/FlatCarbon -pipe -DNDEBUG -DTRIMMED -O -I/usr/X11R6/include -include ../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/MoreFilesX.pp /Users/krmathis/gcc4.0/mozilla/xpcom/MoreFiles/MoreFilesX.c In file included from /Users/krmathis/gcc4.0/mozilla/xpcom/MoreFiles/MoreFilesX.c:80: /Users/krmathis/gcc4.0/mozilla/xpcom/MoreFiles/MoreFilesX.h:1341: error: conflicting types for 'FSLockRange' /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:3373: error: previous declaration of 'FSLockRange' was here /Users/krmathis/gcc4.0/mozilla/xpcom/MoreFiles/MoreFilesX.h:1364: error: conflicting types for 'FSUnlockRange' /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:3427: error: previous declaration of 'FSUnlockRange' was here /Users/krmathis/gcc4.0/mozilla/xpcom/MoreFiles/MoreFilesX.c: In function 'GetTempBuffer': /Users/krmathis/gcc4.0/mozilla/xpcom/MoreFiles/MoreFilesX.c:2654: warning: comparison between signed and unsigned make[4]: *** [MoreFilesX.o] Error 1 make[3]: *** [libs] Error 2 make[2]: *** [tier_2] Error 2 make[1]: *** [default] Error 2 make: *** [build] Error 2 --------------------------
Comment 1•19 years ago
|
||
The subject is misleading. This isn't a GCC 4 conflict, it's a Mac OS X 10.4 conflict. I suspect that the Apple-bundled GCC 3.3 is still preferring an older SDK (10.3, probably) unless told otherwise, and GCC 4 defaults to the 10.4 SDK. Provided you've installed older SDKs (I recall that they're optional and disabled by default, so check!), try building with GCC 4 and the following in your .mozconfig: ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk That's a short-term workaround. Obviously, things should be made to build cleanly against the 10.4 SDK. Apple introduced FSLockRange and FSUnlockRange functions into the system library in 10.4. They should have known better. The FSLockRange and FSUnlockRange functions in Mozilla come straight from Apple, from an older package called MoreFilesX. http://developer.apple.com/samplecode/MoreFilesX/MoreFilesX.html . The declarations of these functions have changed. New API. Bad Apple. Solution 1: apply the enclosed patch to change the names that Mozilla uses, avoiding the clash. This needs to be done if you wish to retain the old interface and let it coexist with the new one. The patch uses the names MFX_FSLockRange and MFX_FSUnlockRange. If anyone so desires, it should be possible to map calls into either of these functions to the new functions provided by the system library, when available. Solution 2: just drop FSLockRange and FSUnlockRange from Mozilla altogether. They're not actually used by anything, so they're just contributing unnecessarily to the bloat. It's not heavy bloat, since both functions are just small wrappers, but I'd just as soon drop them. There's no reason to retain the interfaces at all, let alone under their previous names. There are a bunch of other functions in MoreFilesX that can also be dropped if this route is chosen. All told, I'd guess that it's worth about 10kB in libxpcom_core.
Reporter | ||
Comment 2•19 years ago
|
||
I tried with the 10.2.8.sdk, but now I get a different error. --------------------- checking for correct temporary object destruction order... no configure: error: Your compiler does not follow the C++ specification for temporary object destruction order. *** Fix above errors and then restart with "make -f client.mk build" make: *** [/Users/krmathis/gcc4.0/mozilla/firefox_7450_optimized/Makefile] Error 1 --------------------- Both the 10.2.8 and 10.3.9 sdk are installed. I can successfully build Firefox with GCC 3.3 with the .mozconfig I have been using for months. http://homepage.mac.com/krmathis/Trunk/mozconfig.txt So I cant see why this is a Mac OS 10.4 and not a GCC 4.0 issue...
Comment 3•19 years ago
|
||
Kai, that sounds like a different issue and a different bug - I'm not saying that there aren't/won't be problems with GCC 4, just that the build error you initially posted isn't a GCC 4 problem. If you weren't getting any errors from configure before, and all you did was add with-macos-sdk, then I'm actually kind of surprised that you'd get the destructor error now. But the new error message indicates a different value for MOZ_OBJDIR than you had in the mozconfig you initially posted - I wonder if you didn't inadvertently grab a different mozconfig that specifies hardware or enables specific optimizations? Then things might start to make sense. Try applying the patch and building with GCC 4 without requesting any special SDKs (original mozconfig from comment 0). That ought to get you off the ground, or at least a bit further.
Reporter | ||
Comment 4•19 years ago
|
||
Correct. I used the exact same .mozconfig, but added "ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk" at the end. Then it failed in "checking for correct temporary object destruction order..." No errors from configure before I added the sdk line. The MOZ_OBJDIR used in both cases are "mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox_7450_optimized" (The example .mozconfig in my first post show wrong MOZ_OBJDIR, sorry). I`ll apply the patch and try again!
Reporter | ||
Comment 5•19 years ago
|
||
I applied the patch and started the build process again (without requesting any SDK). This time it passed the previous stag. Compiled for 11 min. compared to 4 minutes... New error message -------------------------- c++ -o nsStandardURL.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"Darwin8.0.0\" -DOSARCH=\"Darwin\" -DBUILD_ID=0000000000 -DIMPL_NS_NET -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/mimetype -I../../../dist/include/uconv -I../../../dist/include/locale -I../../../dist/include/pref -I../../../dist/include/necko -I../../../dist/include -I../../../dist/include/nspr -I../../../dist/sdk/include -I/usr/X11R6/include -mdynamic-no-pic -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fpascal-strings -no-cpp-precomp -fno-common -fshort-wchar -I/Developer/Headers/FlatCarbon -pipe -DNDEBUG -DTRIMMED -O -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/nsStandardURL.pp /Users/krmathis/gcc4.0/mozilla/netwerk/base/src/nsStandardURL.cpp /Users/krmathis/gcc4.0/mozilla/netwerk/base/src/nsStandardURL.cpp: In member function `nsresult nsStandardURL::BuildNormalizedSpec(const char*)': ../../../dist/include/string/nsTSubstring.h:502: error: 'nsCSubstring::nsCSubstring(const nsCSubstring&)' is protected /Users/krmathis/gcc4.0/mozilla/netwerk/base/src/nsStandardURL.cpp:497: error: within this context ../../../dist/include/string/nsTSubstring.h:502: error: 'nsCSubstring::nsCSubstring(const nsCSubstring&)' is protected /Users/krmathis/gcc4.0/mozilla/netwerk/base/src/nsStandardURL.cpp:497: error: within this context make[5]: *** [nsStandardURL.o] Error 1 make[4]: *** [libs] Error 2 make[3]: *** [libs] Error 2 make[2]: *** [tier_9] Error 2 make[1]: *** [default] Error 2 make: *** [build] Error 2
Comment 6•19 years ago
|
||
> /Users/krmathis/gcc4.0/mozilla/netwerk/base/src/nsStandardURL.cpp: In member > function `nsresult nsStandardURL::BuildNormalizedSpec(const char*)': > ../../../dist/include/string/nsTSubstring.h:502: error: > 'nsCSubstring::nsCSubstring(const nsCSubstring&)' is protected > /Users/krmathis/gcc4.0/mozilla/netwerk/base/src/nsStandardURL.cpp:497: error: > within this context This is the same error reported in bug 260402, for what that's worth.
Comment 7•19 years ago
|
||
Got a Tiger in my own tank now. Here are some more notes, now that I've seen the problem first-hand: The 10.2.8 SDK does not include support for GCC 4. The 10.3.9 SDK does, but Apple changed a couple of paths slightly, and the Mozilla configuration system needs to be updated to reflect this. Ditto for targeting the 10.4 SDK by specifying it directly in .mozconfig. In the mean time, target the 10.4 SDK by not specifying any with-macos-sdk option. Comment 1 still stands. So does comment 6. The behavior in comments 5 and 6 is bug 280479. It would be interesting to know if these problems are present in gcc 4.0.0-release, or if they're limited to the (slightly prerelease) version that Apple is shipping.
Depends on: 280479
Comment 8•19 years ago
|
||
*** Bug 292526 has been marked as a duplicate of this bug. ***
Let's try to keep one issue per bug. The nsStandardURL issue is already bug 280479 and bug 260402, so making this bug about the error in comment 0, comment 1, and comment 8.
Summary: Unable to build Firefox with GCC 4.0 → Unable to build Firefox on Tiger due to MoreFilesX conflict with system header
Comment 10•19 years ago
|
||
I fixed this by adding: #ifndef AVAILABLE_MAC_OS_X_VERSION_10_4_AND_LATER ... ... #endif around the declaration and the code in the .c & .h files. This seems to be a little cleaner to me for the purposes of Mozilla. I notice that Apple hasn't updated MoreFilesX (at least publicly) since 2002. I should probably file a bug in Radar/BugReporter at Apple, since FSLockRange & FSUnlockRange have become implemented as of 10.4.
Comment 11•19 years ago
|
||
Shouldn't do that because the prototype has changed, and ifdefing it out like that assumes that FSLockRange is defined the same way in MoreFilesX and in 10.4's system library. It gets renamed out of the way because there's a prototype problem, not just symbol clash (cue cymbals). Mozilla doesn't use FSLockRange, but if it did, with that ifdef, calls to it would have to be similarly conditionalized. If not, calls conforming to the old prototype wouldn't work when built against new SDKs and vice-versa. This issue and many more have been swallowed up in bug 292530. I don't like the dupe of a later bug thing, but this bug seemed to have a different goal when I opened the other one.
The MoreFilesX conflict was fixed as part of bug 292530. Is this bug remaining open for gcc 4 issues (as possibly implied in bug 292530 comment 0 point 3) or should it be closed (Apple's gcc 4 is buggy and doesn't support SDKs needed for software to run on 10.2.x anyway)?
Comment 13•19 years ago
|
||
Dupe this bug to bug 292530, the other gcc 4 issues reported here are gcc bugs, invalid, bug 280479. There are other bugs for legitimate issues with gcc 4, see bug 294244.
Dupe of bug 292530 per comment 13. *** This bug has been marked as a duplicate of 292530 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 15•19 years ago
|
||
Small note: How can an older bug report be a dupe of a new bug report? For me it should be the other way around!
Comment 16•19 years ago
|
||
Kai- When I filed bug 292530, this bug was about gcc 4, and there was no other bug about building on Tiger that didn't involve gcc 4. dbaron subsequently repurposed this bug to be a subset of the other one. This one's the dupe because all of the work was done over there.
Reporter | ||
Comment 17•19 years ago
|
||
Ok, fair enough. Since my goal for this bug report was to build Firefox on Mac OS 10.4 using GCC 4. Which is not possible because of the buggy GCC 4 compiler following the Xcode 2.0 installation.
Reporter | ||
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•