Closed Bug 522028 Opened 16 years ago Closed 15 years ago

Resolve why Mac builds on 1.9.3 sometimes need --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk

Categories

(MailNews Core :: Build Config, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.1rc1

People

(Reporter: standard8, Assigned: standard8)

References

Details

When mozilla-central (1.9.3) transitioned to building on 10.5 and above, after fixing the immediate failures, we found build failures on unit test and leak boxes similar to: CompileC build/TBSpotlight.build/Release/Thunderbird.build/Objects-normal/i386/main.o /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/main.c normal i386 c com.apple.compilers.gcc.4_2 cd /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter /Developer/usr/bin/gcc-4.2 -x c -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -Os -Wreturn-type -Wunused-variable -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.5 -I/builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/build/TBSpotlight.build/Release/Thunderbird.build/Thunderbird.hmap -F/builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/build/Release -I/builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/build/Release/include -I/builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/build/TBSpotlight.build/Release/Thunderbird.build/DerivedSources -c /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/main.c -o /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/build/TBSpotlight.build/Release/Thunderbird.build/Objects-normal/i386/main.o In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12, from /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/main.c:52: NEXT ERROR /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16, from /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/main.c:52: NEXT ERROR /Developer/SDKs/MacOSX10.4u.sdk/usr/include/float.h:8:24: error: float.h: No such file or directory In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:24, from /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/main.c:54: NEXT ERROR /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29:23: error: xmmintrin.h: No such file or directory In file included from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125, from /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:24, from /builds/slave/macosx-comm-central-check/build/objdir/mail/components/search/mdimporter/main.c:54: NEXT ERROR /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:254: error: expected specifier-qualifier-list before '__m128' This builds were fixed by adding: ac_add_options --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk to the mozconfig. I don't know why that fixes it, but it feels wrong that it did. We should therefore check our configure.in in case there is something wrong/missing (the follow-up patch on bug 516858 did not fix this). Setting as proposed-blocking TB 3.1 although it should really block TB 3.next.next, we just don't have flags for that yet.
Flags: blocking-thunderbird3.1?
Depends on: 525331
(In reply to comment #3) > Bug 525331 just fixed this. That is why I added the dependency. > (In reply to comment #2) > > While there, > > http://mxr.mozilla.org/build-central/search?string=MacOSX10.4&case=on&find=%2Fmacosx%2Fcomm-1.9.1%2F > > should not be needed, should it? > > (Still there.) Not surprising as my plan was to fix bug 525331 and then come up and fix this bug later as indicated by the dependency.
Assignee: nobody → bugzilla
Flags: in-testsuite-
(In reply to comment #4) > That is why I added the dependency. > Not surprising as my plan was to fix bug 525331 and then come up and fix this > bug later as indicated by the dependency. So what? I simply updated the status here...
Status: NEW → ASSIGNED
(In reply to comment #5) > So what? I simply updated the status here... Apart from the fact the error was fixed (which I'd have annotated today anyway) the rest was effectively a useless comment.
I checked in a change: http://hg.mozilla.org/build/buildbot-configs/rev/bc87ec6221f1 to the buildbot configs to remove the: ac_add_options --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk line from the unit test (MacOSX 10.5 comm-1.9.1 check) mozconfig. I clobbered the builds at the same time and the first box has cycled green, so it looks like it is holding now. As the mac builders are slow and need to do l10n builds etc, I'll deal with the other cleanup over the next few days.
Another change, this time to the bloat boxes: http://hg.mozilla.org/build/buildbot-configs/rev/07c3f79a74bd (I also removed the option from the shark mozconfig even though we don't use it at the moment). I've clobbered the trunk bloat boxes alongside it so there will be some long builds today, but hopefully it'll be relatively quiet. Still some more tidy up to do, will think about it over the next few days.
Removed the last --with-macos-sdk option from the 1.9.1 unit test mozconfig: http://hg.mozilla.org/build/buildbot-configs/rev/a15738404741 I've clobbered the builds even though in theory it won't change anything. Still got the LDAP c-sdk issue to look at, though from a brief glance it probably isn't an issue but maybe something for tidy up later.
I don't think this blocks 3.1 - please correct me if I'm wrong.
Flags: blocking-thunderbird3.1? → blocking-thunderbird3.1-
(In reply to comment #9) > Removed the last --with-macos-sdk option from the 1.9.1 unit test mozconfig: > ... > > Still got the LDAP c-sdk issue to look at, though from a brief glance it > probably isn't an issue but maybe something for tidy up later. Do we want to resolve this bug and do a new one for the LDAP c-sdk then? Or some combination?
I've now taken another look at the LDAP c-sdk usage of MacOSX10.4.sdk, it appears that is only used for evaluating cross-compile in some instances. It doesn't appear to affect us (our 64 bit minis don't have the 10.4 SDK installed), and the code is currently the same as the NSPR configure code. So for now, I'm going to leave the LDAP code alone, and hence this bug can be resolved as fixed.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1rc1
You need to log in before you can comment on or make changes to this bug.