Closed Bug 188246 Opened 17 years ago Closed 17 years ago

Build NSPR with GCC 3.x

Categories

(NSPR :: NSPR, defect)

x86
OS/2
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jhpedemonte, Assigned: wtc)

References

Details

Attachments

(3 files, 8 obsolete files)

Derived from Meta bug 177789.  This bug deals specifically with patches to make
NSPR build on OS/2 using GCC 3.0.3
Attached patch preliminary patch (obsolete) — Splinter Review
First patch.  Still to do:
1) Write RAMSEM code.
2) Write atomic ops code.
3) Any other TODO or anything that looks odd in the patch.
Don't remember what the RAMSEM code is about, but a trivially tweaked Linux i386
atomic ops code has been working fine here for many moons. I sent Mike the file
way back then.
Attached patch patch w/ atomic ops asm (obsolete) — Splinter Review
Patch contains assembly code for atomic ops.  Also, got pr/tests building. 
Many tests fail.
Attachment #110985 - Attachment is obsolete: true
Attached patch patch v3 (obsolete) — Splinter Review
General code cleanup.  Still TODO:
   1) Write RAMSEM code.
   2) Figure out SIGFPE crash (either here or in JS)
Attachment #111754 - Attachment is obsolete: true
Attached patch patch v3.1 (obsolete) — Splinter Review
Define BSD_SELECT in the correct place (fixes startup crash).
Attachment #116127 - Attachment is obsolete: true
Attached patch patch v3.2 (obsolete) — Splinter Review
More cleanup.
Attachment #116253 - Attachment is obsolete: true
Summary: Build NSPR with GCC 3.0.3 → Build NSPR with GCC 3.x
Attached patch patch v3.3 (obsolete) — Splinter Review
Thread & tests fixes
Attachment #117252 - Attachment is obsolete: true
Attachment #118053 - Flags: review?(wtc)
Attached patch patch v3.4 (obsolete) — Splinter Review
Fix Visual Age bustage
Attachment #118053 - Attachment is obsolete: true
Attachment #118079 - Flags: review?(wtc)
Attachment #118053 - Flags: review?(wtc)
Comment on attachment 118079 [details] [diff] [review]
patch v3.4

Javier,

Is it possible for you to generate a new patch that
does NOT have the DEF_FILE related changes?  The
reason is that we will need to change them again
when we check in the patch in bug 190538.  Also,
DEF_FILE is the same as the existing MAPFILE.
In other words, is it possible to do a GCC 3.x build
without a DEF_FILE?
wtc:  Yes, we do need DEF files for the GCC build.  The changes here are just to
clean up the code the generates the DEF file.
PRThread*                                                                      
                               
_MD_CURRENT_THREAD(void)                                                       
                               
{                                                                              
                               
    PRThread *thread;                                                          
                               
                                                                               
                               
    thread = _MD_GET_ATTACHED_THREAD();                                        
                               
                                                                               
                               
    if (NULL == thread) {                                                      
                               
        thread = _PRI_AttachThread(PR_USER_THREAD, PR_PRIORITY_NORMAL, NULL, 0);
                              
    }                                                                          
                               
                                                                               
                               
    PR_ASSERT(thread != NULL);                                                 
                               
    return thread;                                                             
                               
}                                                                              
                               

Is in os2tred.c twice after the patch.  
Attached patch patch v3.5Splinter Review
Cleaned up rules.mk to use existing MAPFILE macro.
Attachment #118079 - Attachment is obsolete: true
Attachment #118079 - Flags: review?(wtc)
Attachment #118493 - Flags: review?(wtc)
Attached patch wtc's patch (obsolete) — Splinter Review
Javier, could you test this patch?  Thanks.
wtc:  Yes, that patch works, except that it is missing the os2emx.s file from
the previous patch.  Put that in also, and this patch works for me.
Attached patch wtc's patch v2Splinter Review
Sorry, I missed os2emx.s.  This patch includes it.
I also removed your changes to nsprpub/pr/tests/dll/Makefile.in
from this patch.  Can you build in that directory without these
changes?  In any case, these changes are not required for the
Mozilla client.

Turns out your patch v3.5 is essentially the same as my patch.
We were working on and attaching our patches at pretty much the
same time :-)

I've checked in this patch on the NSPRPUB_PRE_4_2_CLIENT_BRANCH
for mozilla 1.4alpha.
Attachment #118497 - Attachment is obsolete: true
Changes necessary for NSPR tests to build.  Also, removed $(TARGETS) define
(now handled by rules.mk) so *.lib would get deleted by 'make clean'.
Comment on attachment 118557 [details] [diff] [review]
nsprpub/pr/tests/dll/Makefile.in changes

You deleted
    else
    TARGETS		= $(SHARED_LIBRARY) $(IMPORT_LIBRARY)
which is used by WINNT.  This should be restored.

It seems that for OS/2, TARGETS must include $(LIBRARY) because
$(MAPFILE) is generated from $(LIBRARY), right?
Attachment #118557 - Flags: review-
For the purpose of building Mozilla with GCC 3.x (meta bug 177789),
this bug is fixed.  The necessary changes for building NSPR as part
of Mozilla will appear in mozilla 1.4alpha.

Javier, please use bug 126932 (NSPR tests don't run on OS/2) for
the remaining changes for nsprpub/pr/tests/dll/Makefile.in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [4.3.1]
Target Milestone: --- → 4.3
Attachment #118493 - Flags: review?(wchang0222)
Whiteboard: [4.3.1]
Target Milestone: 4.3 → 4.4
You need to log in before you can comment on or make changes to this bug.