106617 - Drop rhapsody & add darwin support to NSPR

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P2)

Description

[hacker formerly known as [e-mail]]

Spinoff from bug 75653.  I want to officially drop support for rhapsody and add
support for darwin.  With the exception of the dangling rhapsody references,
it's already mostly done as the configure test will only set up a build for
boxes that identify themselves as *-darwin* not *-rhapsody*.  In addition to the
patch to be attached, the following files will need to be rechecked in under
their new darwin name:

nsprpub/pr/include/md/_darwin.cfg
nsprpub/pr/include/md/_darwin.h
nsprpub/pr/src/md/unix/darwin.c

Comment 1

[hacker formerly known as [e-mail]]

Attachment: Change dangling rhapsody references to darwin

Comment 2

[Wan-Teh Chang]

Chris, your patch (attachment 55016 [details] [diff] [review]) is fine.  r=wtc.

Two comments:
1. There are two changes in your patch that are unrelated
to the Rhapsody->Darwin renaming.  One is the addition of
-traditional-cpp to CFLAGS, and the other is the addition
of -install_name @executable_path/$@ to MKSHLIB.  Could
you explain what these two changes are for?  In particular,
does NSPR really need -traditional-cpp?

2. In the three files (_rhapsody.cfg, _rhapsody.h, and
rhapsody.c), references to "rhapsody", "RHAPSODY", and
"Rhapsody" also need to be changed to "darwin", "DARWIN",
and "Darwin".  We will need another patch for these
three files.

Comment 3

[hacker formerly known as [e-mail]]

1) The changes came from the mach-o osx branch so I'm not exactly sure why
-traditional-cpp is needed.  beard?   -install_name @executable_path appears to
be a special linker flag that lets the app that links against libnspr know where
it should be found.  In this case, in the same directory as the executable for
the application.  In the clear light of day, maybe we don't want to hardcode
that for all *darwin versions since there's an x86 darwin port & you could build
against X11 rather than the OSX API.

2) Those changes are already done in my tree.  I need to contact dawn about
copying the cvs repo *rhapsody* files to *darwin* so that we preserve cvs history.

Comment 4

[hacker formerly known as [e-mail]]

the nsprpub/*rhapsody* files have been copied over to nsprpub/*darwin* and their
changes have been checked in.

Comment 5

[Patrick C. Beard]

We need to use "-install_name @executable_path" to find all of the shared
libraries that are built into dist/bin, when running as a packaged (Mozilla.app)
application. This should probably be a configurable option, that isn't needed
when run in a pure darwin environment, which would presumably use X windows.

Comment 6

[hacker formerly known as [e-mail]]

The rhapsody -> darwin naming changes have been checked in.  Wrt the additional
OSX flags, I have a patch that adds --enable-osx-hack to NSPR.  Mozilla's
configure will add it when it call's NSPR's configure.  It strikes me as
slightly unclean so I'm open to better suggestions.

Comment 7

[hacker formerly known as [e-mail]]

Attachment: add --enable-osx-hack to handle OSX reqs

Comment 8

[Wan-Teh Chang]

Comment on attachment 55189 [details] [diff] [review]
add --enable-osx-hack to handle OSX reqs

I object to the use of the -traditional-cpp compiler flag.
It causes the macros __STDC__ and __STDC_VERSION__ to
be not defined.

I still need to think about the -install_name @executable_path/\$@
linker flag.  It is okay to always use it.
I don't like an option with "hack" in it :-)

Comment 9

[Wan-Teh Chang]

I found that the -traditional-cpp flag of cc on
Mac OS X 10.1 does not work as specified in
"Using and Porting GNU CC", Version 2.95, p.16.

On Mac OS X 10.1, __STDC__ is defined to be 1,
whether -traditional-cpp is used or not.
__STDC_VERSION__ is not defined unless
-traditional-cpp is used, in which case
__STDC_VERSION__ is defined to be 199409.

I am confused.

Comment 10

[hacker formerly known as [e-mail]]

Ok, I removed the *hack option and just added -traditional-cpp & -install_name
to CFLAGS & DSO_LDOPTS, respectively.  I checked this in on the client branch so
that we can get some traction on the much larger osx patch.  I'm not sure what
the deal is with the -traditional-cpp option but I do know that darwin's version
of gcc is still in flux so it could just be a bug.

Comment 11

[Wan-Teh Chang]

I think -traditional-cpp should be removed from NSPR.
Clearly it is not required to compile NSPR, and
according the the GNU CC documentation it is wrong
to use -traditional-cpp when compiling a piece of
modern C code.

Comment 12

[Patrick C. Beard]

I believe that -traditional-cpp is simply to not use precompiled headers. I
think the latest compiler has an explicit option for this, something like
-no-precomp that should be used instead.

Comment 13

[Wan-Teh Chang]

Chris, could you also check this in on the tip of NSPR?
Thanks.

Comment 14

[hacker formerly known as [e-mail]]

From file://localhost/Developer/Documentation/DeveloperTools/Compiler/C 
ompiler.a.html#pgfId=4991

"
   Mac OS X includes two preprocessors: the standard GNU C preprocessor (       
   cpp ) and the precompilation preprocessor ( cpp-precomp ). The two           
   preprocessors are largely similar, except for some rarely used               
   extensions. The precompilation preprocessor( cpp-precomp ) is the            
   default preprocessor for C and Objective-C code. (See                        
   /System/Documentation/Developer/DeveloperTools/Preprocessor/ for more        
   information. ) The standard preprocessor ( cpp ) is the default              
   preprocessor for Objective-C++ code. To switch to the standard               
   preprocessor ( cpp ) on platforms on which precompiled headers are           
   available, use the -traditonal-cpp flag on the cpp command line.             
"

Ok. NSPR's small so we can live without the speedup from using precompiled
headers. Btw, when I try to compile hello.c with -precomp, cc spits out a
warning and hello is not executable.

Comment 15

[Wan-Teh Chang]

Chris, thanks for the info on the two preprocessors
and the -traditional-cpp flag.

I am not advocating the use of pre-compiled headers,
nor do I object to the use of the standard preprocessor.
I am proposing that NSPR should use the default
preprocessor unless the -traditional-cpp flag is
required to compile NSPR.

Comment 16

[Wan-Teh Chang]

Chris, after reading this bug report again, I think it's
good to use the -traditional-cpp flag. It is a shame that
the Mac OS X compiler overloaded the meaning of this GNU C
compiler flag, which is confusing. 

Could you please add this comment to nsprpub/configure.in
+    # Use the standard preprocessor (cpp).
     CFLAGS="$CFLAGS -traditional-cpp"
and merge your patch on the tip of NSPR?  Thanks.

Comment 17

[hacker formerly known as [e-mail]]

Note added to configure.in .  Change have been checked into the NSPR tip. 
Marking fixed.

Comment 18

[Patrick C. Beard]

Groveling through the gcc sources, I find several occurrences of a "-noprecomp"
command line option, which presumably causes the traditional cpp to be used. It
occurs in both gcc.c (line 967) and cccp.c (line 2404). That last filename
always cracks me up. An Apple compiler engineer told me we should use that flag
instead of -traditional-cpp.

Comment 19

[Patrick C. Beard]

Never mind. That option doesn't work with the compiler I'm using.

Comment 20

[Patrick C. Beard]

Ah, the compiler flag we want is -no-cpp-precomp. I've just rebuilt mach-o NSPR
with this flag instead of traditional-cpp.

Comment 21

[hacker formerly known as [e-mail]]

Ok, switched to using -no-cpp-precomp for NSPR on Darwin.