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)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 292530

People

(Reporter: krmathis, Unassigned)

References

Details

Attachments

(1 file)

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
--------------------------
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.
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...
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.
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!
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
> /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.
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
*** 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
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.
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)?
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
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!
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.
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.

Status: RESOLVED → VERIFIED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: