Closed Bug 153525 Opened 22 years ago Closed 22 years ago

Allow mach-o build to build on gcc3

Categories

(SeaMonkey :: Build Config, defect, P1)

Product:
SeaMonkey
Component:
Build Config
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: dbaron, Assigned: bryner)

Details

(Whiteboard: [patch])

Attachments

(2 files, 10 obsolete files)

another new patch
10.88 KB, patch
netscape
: review+
asa
: approval+
Details | Diff | Splinter Review
Alternative patch for NSPR, v2
3.24 KB, patch
Details | Diff | Splinter Review 
I've been working on getting the mach-o build to build with the gcc3
in Apple's April 2002 Dev Tools beta.  Anyway, to describe the changes
I have so far in more detail:

-----

The new compiler/linker combination doesn't like linking C++ files
using gcc3 rather than g++3.  This led to the changes in
config/Makefile.in to get asdecode to be linked with $(CXX) rather
than $(CC).  However, this is somewhat of a hack (it forces the
same thing to happen to nsinstall, which does no harm, and it's
Darwin-only), but asdecode should really be in its own directory.

-----

This patch uses ifdefs, etc., to port the ppc-rhapsody xptcall code
to gcc3 so that it still works on gcc 2.95.  Parts of the patch
are based on Glenn Nakamura's patch in bug 86446.

TestXPTCInvoke works fine in both my 2.95 and 3.1 builds.

I can easily rewrite this part after bryner lands his patch to the xptcall
code that he needs for prebinding.

-----

The old gcc passed -install_name through to libtool (for -dynamiclib)
but filtered it out for ld.  The new one doesn't filter for ld
(which is used to link -bundle libraries), so we can't pass
-install_name when using -bundle.  However, beard thinks this is probably
OK, and my 2.95 build still works fine.  (I'm using it to write this
bug report.)

-----

The compiler has one major bug that I need to report.  I've worked
around it a bit, but it finally got to one point where the workaround
stopped working.  Some of the workarounds are probably good code
changes that we'd want to check in.  The bug is that the compiler
chokes on non-const static variables in inline static member functions.
I fixed a large number of them by converting hand-crafted GetIID
functions that didn't use |const| to use NS_DEFINE_STATIC_IID_ACCESSOR.
These seem like changes that we may as well check in.  However, some of
the changes shouldn't be checked in.

I need to file a compiler bug, but ADC login that I created yesterday
didn't seem to work at http;//bugreporter.apple.com/ .

Examples of the error messages before these changes are:

/Users/dbaron/builds/trunk/mozilla/xpcom/ds/nsIArena.h: In function `static 
   const nsIID& nsIArena::GetIID()':
/Users/dbaron/builds/trunk/mozilla/xpcom/ds/nsIArena.h:61: nsIID iid causes a 
   section type conflict

/Users/dbaron/builds/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:47
4: WrappedJSIdentity*singleton
    causes a section type conflict

The don't-check-this-in changes are particularly in the files:
  js/src/xpconnect/src/xpcwrappedjsclass.cpp
  perhaps the caps changes, although I prefer my way...

-----

I'd probably like to get parts of the changes I have so far checked in.
I'll attach a patch with everything I've done, and then perhaps split it
into things that I'd like to get checked in sometime later.
This is the whole patch that allows me to build up through htmlparser, at which
point building CNavDTD.cpp chokes on a pile of section conflict errors.  It
also allows TestXPTCInvoke to run correctly.  Only parts of this patch should
ever be considered for checkin.
I managed to find a workaround to get past the problem in htmlparser, to the point where I can finish the build.  And, anyway, it works.  At least, it works well enough for me to be submitting this comment using it.  And this is an -O2 build.

I'll attach the patch that I have so far in pieces.
These are workarounds, but probably worth checking in since they make more data
const.
This is the version merged with bryner's changes for prebinding (the macro
hacks are a bit different in m4 from the way they were in C++, but the idea is
the same).
Attachment #88843 - Attachment is obsolete: true
Comment on attachment 88844 [details] [diff] [review]
patch v. 1.0: build changes that aren't workarounds

r=bryner
Attachment #88844 - Flags: review+
Comment on attachment 88882 [details] [diff] [review]
patch v. 2.0: xptcall porting changes

r=bryner
Attachment #88882 - Flags: review+
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.1beta
Comment on attachment 88845 [details] [diff] [review]
patch v. 1.0: GetIID constness/macro changes

r=/sr=jag
Attachment #88845 - Flags: superreview+
Comment on attachment 88844 [details] [diff] [review]
patch v. 1.0: build changes that aren't workarounds

sr=beard
Attachment #88844 - Flags: superreview+
Comment on attachment 88882 [details] [diff] [review]
patch v. 2.0: xptcall porting changes

sr=beard
Attachment #88882 - Flags: superreview+
Comment on attachment 88882 [details] [diff] [review]
patch v. 2.0: xptcall porting changes

Checked in 2002-06-25 20:01 PDT.
Attachment #88882 - Attachment is obsolete: true
Comment on attachment 88844 [details] [diff] [review]
patch v. 1.0: build changes that aren't workarounds

Checked in 2002-06-25 20:02/07/09 PDT.
Attachment #88844 - Attachment is obsolete: true
Comment on attachment 88845 [details] [diff] [review]
patch v. 1.0: GetIID constness/macro changes

r=bryner
Attachment #88845 - Flags: review+
Comment on attachment 88845 [details] [diff] [review]
patch v. 1.0: GetIID constness/macro changes

Checked in 2002-06-25 20:37/38 PDT.
Attachment #88845 - Attachment is obsolete: true
These are additional changes I needed to compile on Jaguar 6C75, in which the
two serious compiler bugs (the section type conflict and the objective C
linking problem) have been fixed.

The changes are:
 * -compatibility_version and -current_version can only be used with
-dynamiclib
 * the /rsrc hack used by asdecode.cpp doesn't seem to work anymore, but bryner
found a workaround -- it does work when opening the file as read-write.
 * siginfo_t is now typedefed in system headers to something that begins with
underscores, so the typedef in nspr disagrees with the one in the system
headers.  I hope that wasn't really needed for the old version of the OS.  I'll
need to test that...
Attachment #88903 - Attachment is obsolete: true
(But, FWIW, it was somewhat difficult to get the tools set up on Jaguar 6C75.  I
had to make a one line change to /sw/lib/fink/update/ltconfig in order to get
glib to build:

=====
--- ltconfig    Tue Jul  2 20:01:43 2002
+++ ltconfig    Tue Jul  2 20:02:01 2002
@@ -1381,7 +1381,7 @@
       allow_undefined_flag='-flat_namespace -undefined suppress'
       ;;
     esac
-    archive_cmds='$nonopt $(test .$module = .yes && echo -bundle || echo -dynam
iclib) $allow_undefined_flag -o $lib $libobjs $deplibs $linkopts -install_name $
rpath/$soname $verstring'
+    archive_cmds='$nonopt $(test .$module = .yes && echo -bundle || echo -dynam
iclib -install_name $rpath/$soname) $allow_undefined_flag -o $lib $libobjs $depl
ibs $linkopts $verstring'
     # We need to add '_' to the symbols in $export_symbols first
     #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols $lib'
     hardcode_direct=yes
=====

and then I couldn't get orbit to build at all -- I ran into a linker problem
that I couldn't fix by using gcc2 and couldn't fix by using the unstable orbit
package (0.5.15 instead of 0.5.12).  I ended up copying the .deb over from a
10.1.5 system (/sw/fink/debs/orbit_0.5.12-1_darwin-powerpc.deb).)
Comment on attachment 90173 [details] [diff] [review]
patch needed for compiling on Jaguar 6C75

What's up with "do { } while (0)" in the EXIT_IF_FALSE macro?  Does that have
some effect other than just executing the block of code once?

The man page claims that "b" has no effect for fopen(), so that can probably be
removed.
> What's up with "do { } while (0)" in the EXIT_IF_FALSE macro?  Does that have
> some effect other than just executing the block of code once?

That's what PR_BEGIN_MACRO and PR_END_MACRO are -- it makes a macro that can be
used syntactically like a function.
Shouldn't this bug block bug 71627

Also bug 150106 should be marked a dup of this bug... or am I just off in both
cases?
Target Milestone: mozilla1.1beta → mozilla1.2alpha
As a random asside, is there any chance of this making it over to the 1.0
branch? (once it's been stable on the trunk for a few weeks, obviously). I find
it hard to gauge whether the fixes above would be considered 'low-risk' or not,
but it would be helpful to know either way.
Probably not.  After all, the final part hasn't even landed on the trunk yet
(since I haven't had a chance to test it on 10.1 + gcc 2.95).
This breaks on gcc 2.95, with an error because siginfo_t is not defined (in
nsprpub/pr/src/md/unix/darwin.c).

-> me, since dbaron is now mac-less.
Assignee: dbaron → bryner
Status: ASSIGNED → NEW
Attached patch new patch (obsolete) — — Splinter Review 
This patch uses an autoconf test to see whether nspr needs to define siginfo_t.
 I've tested that this compiles on both gcc 3 and 2.95.
Attachment #90173 - Attachment is obsolete: true
Comment on attachment 92116 [details] [diff] [review]
new patch

You should use AC_CACHE_VAL to cache the results of that test so that we don't
re-run it with every configure.  Also, since it is a generic test, you should
move it out of the darwin section.
Attachment #92116 - Flags: needs-work+
Ok, this should address seawood's comments.
Attachment #92116 - Attachment is obsolete: true
Comment on attachment 92119 [details] [diff] [review]
another new patch

r=cls
Attachment #92119 - Flags: review+
wtc, could you review the NSPR portion of this patch, and check it in when it
gets approval? (I don't have access to check into nsprpub/).  We'll want this on
the client branch as well.  Thanks.
Status: NEW → ASSIGNED
Comment on attachment 92119 [details] [diff] [review]
another new patch

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #92119 - Flags: approval+
Comment on attachment 92119 [details] [diff] [review]
another new patch

In mozilla/nsprpub/pr/src/md/unix/darwin.c

>+#ifndef HAVE_SIGINFO_T
> typedef struct siginfo_t siginfo_t;
>+#endif
> 
> int sigtimedwait(const sigset_t *set, siginfo_t *info,
>     const struct timespec *timeout)

Perhaps we should just use 'struct siginfo_t' in the
declaration of our signtimedwait stub function and get
it over with?

We should also submit a bug report against gcc3.
A bug about what?  signal.h on jaguar defines siginfo_t as as typedef; with the
December 2001 tools, signal.h does not define siginfo_t.

Yeah, we could just change it to "struct siginfo_t" if you'd like.  It looks
like we only ever pass NULL for that parameter inside NSPR.

I thought the problem was that in Jaugar, siginfo_t was typedef-ed to something
with leading underscores (i.e., not |struct siginfo_t|), and therefore the
typedef that was included in NSPR was redeclaring the typedef differently from
the way it was initially declared.  (That change wasn't a gcc issue, it was a
Jaguar issue -- different version of the OS.)
dbaron is right.  there is no "struct siginfo" or "struct siginfo_t" in jaguar.
Attached patch Alternative patch for NSPR (obsolete) — — Splinter Review 
This alternative patch for NSPR avoids the need for
the siginfo_t type altogether.	I also removed the
code defining the unused PT_NO_ATFORK macro.
Comment on attachment 92470 [details] [diff] [review]
Alternative patch for NSPR

r=bryner.

I should note that Jaguar _does_ appear to have pthread_condattr_init and
pthread_kill, but that can be addressed later.
Attachment #92470 - Flags: review+
The pthread_condattr_init call is not important to NSPR.
The pthread_kill function is only used in NSPR's garbage
collection support code.  Unless NSPR is used as the
underpinnings of some JVM, the GC support code is not
important. (In fact, it may have rotted.)
wtc's last checkin broke the Mozilla MachO build (planetoid). bryner and I made
this change to fix it:

Index: mozilla/nsprpub/pr/src/pthreads/ptthread.c
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/pr/src/pthreads/ptthread.c,v
retrieving revision 3.42.2.3
diff -u -4 -r3.42.2.3 ptthread.c
--- mozilla/nsprpub/pr/src/pthreads/ptthread.c	14 Mar 2002 23:21:11 -0000	3.42.2.3
+++ mozilla/nsprpub/pr/src/pthreads/ptthread.c	24 Jul 2002 03:48:02 -0000
@@ -1219,9 +1219,9 @@
 	pthread_cond_signal(&me->suspendResumeCV);
 	while (me->suspend & PT_THREAD_SUSPENDED)
 	{
 #if !defined(FREEBSD) && !defined(NETBSD) && !defined(OPENBSD) \
-    && !defined(BSDI) && !defined(VMS) && !defined(UNIXWARE)  /*XXX*/
+    && !defined(BSDI) && !defined(VMS) && !defined(UNIXWARE) &&
!defined(DARWIN)  /*XXX*/
         PRIntn rv;
 	    sigwait(&sigwait_set, &rv);
 #endif
 	}

I've checked this in to NSPRPUB_PRE_4_2_CLIENT_BRANCH and the NSPR tip.
Yes, that's the right fix.  Thank you, Simon and Brian!
Attachment #92470 - Attachment is obsolete: true
I checked in the remaining part of the fix to the trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment on attachment 88846 [details] [diff] [review]
patch v. 1.0: hacky workarounds

Obsoleted by fixes to the newer gcc3 dev tools
Attachment #88846 - Attachment is obsolete: true
The asdecode.cpp changes were backed out.  Is that still an issue for building
on Jaguar?
Nope, nightly mach-o and chimera builds are being done on jaguar.
Mozilla has stopped building (Mach-O) under 10.2 with this error message:

c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-long-long -fpascal-strings -traditional-cpp -fno-common
-I/Developer/Headers/FlatCarbon -F/System/Library/Frameworks -pipe  -DNDEBUG
-DTRIMMED -O -I/Developer/Headers/FlatCarbon -F/System/Library/Frameworks -fPIC
-arch ppc -o libxpcom.dylib  nsXPComInit.o  pldhash.o plvector.o nsArena.o
nsAtomTable.o nsAtomService.o nsByteBuffer.o nsCheapSets.o nsCRT.o
nsConjoiningEnumerator.o nsDeque.o nsEmptyEnumerator.o nsEnumeratorUtils.o
nsFixedSizeAllocator.o nsHashSets.o nsHashtable.o nsHashtableEnumerator.o
nsObserver.o nsObserverList.o nsObserverService.o nsProperties.o
nsPersistentProperties.o nsQuickSort.o nsRecyclingAllocator.o nsSizeOfHandler.o
nsStaticNameTable.o nsStatistics.o nsSupportsArray.o nsSupportsArrayEnumerator.o
nsSupportsPrimitives.o nsUnicharBuffer.o nsVariant.o nsVoidArray.o
nsTextFormatter.o nsTimelineService.o nsValueArray.o nsCOMArray.o nsArray.o
nsArrayEnumerator.o nsAppFileLocationProvider.o nsBinaryStream.o
nsByteArrayInputStream.o nsDirectoryService.o nsEscape.o nsFastLoadFile.o
nsFastLoadService.o nsFileSpec.o nsFileSpecImpl.o nsFileStream.o nsIFileStream.o
nsStringStream.o nsInputStreamTee.o nsLinebreakConverter.o nsLocalFileCommon.o
nsMultiplexInputStream.o nsPipe2.o nsScriptableInputStream.o nsSegmentedBuffer.o
nsSpecialSystemDirectory.o nsStorageStream.o nsUnicharInputStream.o
nsNativeCharsetUtils.o nsLocalFileOSX.o nsCategoryManager.o nsComponentManager.o
nsComponentManagerObsolete.o nsNativeComponentLoader.o nsRegistry.o
nsServiceManagerObsolete.o xcDll.o plevent.o nsAutoLock.o nsEventQueue.o
nsEventQueueService.o nsThread.o nsTimerImpl.o nsProcessCommon.o TimerThread.o
nsProxyEvent.o nsProxyEventClass.o nsProxyEventObject.o nsProxyObjectManager.o
nsAllocator.o nsMemoryImpl.o nsErrorService.o nsTraceRefcnt.o nsID.o
nsCWeakReference.o nsConsoleService.o nsConsoleMessage.o nsExceptionService.o
xptcall.o xptiFile.o xptiInterfaceInfo.o xptiInterfaceInfoManager.o
xptiManifest.o xptiMisc.o xptiTypelibGuts.o xptiWorkingSet.o xptiZipItem.o
xptiZipLoader.o xpt_arena.o xpt_struct.o xpt_xdr.o xptcinvoke_ppc_rhapsody.o
xptcstubs_ppc_rhapsody.o xptcinvoke_asm_ppc_rhapsody.o
xptcstubs_asm_ppc_darwin.o reg.o VerReg.o vr_stubs.o nr_bufio.o
nsASingleFragmentString.o nsAString.o nsDependentConcatenation.o
nsDependentSubstring.o nsFragmentedString.o nsPrintfCString.o
nsPromiseFlatString.o nsReadableUtils.o nsSharableString.o nsSharedBufferList.o
nsSlidingString.o nsXPIDLString.o nsStr.o nsString.o nsString2.o nsCOMPtr.o
nsDebug.o nsGenericFactory.o nsIInterfaceRequestorUtils.o nsMemory.o
nsWeakReference.o nsComponentManagerUtils.o    
../../dist/lib/libmacmorefiles_s.a -dynamiclib -install_name
@executable_path/\libxpcom.dylib -compatibility_version 1 -current_version 1
-L/mozilla/mozcurrent/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl 
-framework Carbon /System/Library/Frameworks/Carbon.framework/Carbon -ldl -lm     
ld: Undefined symbols:
nsXPTCStubBase::Stub3()
nsXPTCStubBase::Stub4()
nsXPTCStubBase::Stub5()
nsXPTCStubBase::Stub6()
nsXPTCStubBase::Stub7()
nsXPTCStubBase::Stub8()
nsXPTCStubBase::Stub9()

....
nsXPTCStubBase::Stub240()
nsXPTCStubBase::Stub241()
nsXPTCStubBase::Stub242()
nsXPTCStubBase::Stub243()
nsXPTCStubBase::Stub244()
nsXPTCStubBase::Stub245()
nsXPTCStubBase::Stub246()
nsXPTCStubBase::Stub247()
nsXPTCStubBase::Stub248()
nsXPTCStubBase::Stub249()
make[4]: *** [libxpcom.dylib] Error 1
make[3]: *** [libs] Error 2

I am building with these options:
#ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
#ac_add_options --enable-crypto
#ac_add_options --enable-extensions
ac_add_options --enable-stripped

mk_add_options MOZ_MAKE_FLAGS=-j4

on a dual GHz PowerMac G4 (768MB)  I am building with gcc3.

p.s. I have a 450MHz G4 sitting under the desk gathering dust.  It has 10.2 and
768MB or RAM, I would like to volunteer it for a Tinderbox test rig for 10.2
with gcc3.  If this helps contact me by email
This is a problem with your orbit installation. You need to make sure you
updated fink, remove mozilla/config.cache, and do a make distclean.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: