Closed
Bug 81031
Opened 23 years ago
Closed 23 years ago
NSPR configure script passes -pipe unconditionally
Categories
(NSPR :: NSPR, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
4.2
People
(Reporter: jim_nance, Assigned: cls)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review |
I am playing with the Beta of Intel's Linux C/C++ compilers. I am having
problems building nspr because the configure script passes in -pipe which causes
things to fail since the intel compilers dont know about that flag. Removing
the -pipe strings from mozilla/nspr/configure and the Linux.mk file seems to
have fixed this problem.
The platform sections of the configure script were a direct port from the
config/<platform>.mk files which made some ..um, assumptions. We need to either
port the general -pipe check from Mozilla's configure or add another case switch
for the intel compiler in NSPR's configure.
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
Thanks chis. I looked at the patch and I think it does the right thing, but I
want to make sure. If the compiler is NOT gcc, it does not pass in the -pipe right?
If you're not using gcc, g++ *and* gnu as, then configure doesn't even attempt
the -pipe test. If all of those conditions are met, then it still tests that AS
can take input from stdin (which is how -pipe works) and that $(CC) -pipe also
works.
wtc, are there any issues with checking this into the trunk as well? On a
slightly unrelated note, what are the plans for c++ support in nspr? If it's no
longer supported, then I'll remove the GNU_CXX requirement from the patch.
Moving to NSPR product.
Assignee: cls → wtc
Component: Build Config → NSPR
Product: Browser → NSPR
QA Contact: granrose → wtc
Target Milestone: mozilla0.9.4 → 4.2
Version: other → 4.0.2
Comment 8•23 years ago
|
||
Other priorities. I have an updated patch in my tree that I need to update though.
Comment 9•23 years ago
|
||
Attachment #40830 -
Attachment is obsolete: true
Comment 10•23 years ago
|
||
Patch has been checked into the tip & the NSPRPUB_PRE_4_2_CLIENT_BRANCH .
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 11•23 years ago
|
||
Comment on attachment 57880 [details] [diff] [review]
Updated version
The --disable-gcc-pipe configure option shouldn't be
added. Other than that, this patch is fine.
What is the intended use of the --disable-gcc-pipe option?
Attachment #57880 -
Flags: needs-work+
Comment 12•23 years ago
|
||
Bryner opened another bug to handle Intel's Linux C/C++ compilers
(bug 102059). In that bug, he treats the Intel compiler as a
separate compiler as opposed to a gcc variant. Perhaps that's a
better solution? I guess the answer depends on how hard Intel
tries to maintain gcc compatibilty.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 13•23 years ago
|
||
The option is used to turn off the -pipe detection. On a sparc solaris using an
older binutils, there was an as that did not accept input from stdin. I no
longer have access to that config so I left the --disable-gcc-pipe option in as
a workaround in case the auto-detect didn't work for some reason.
Comment 14•23 years ago
|
||
The --disable-gcc-pipe configure option has been removed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 15•23 years ago
|
||
Chris, although I agree that the --disable-gcc-pipe configure
option should be removed, I'd like to know why you decided to
do that.
Comment 16•23 years ago
|
||
I didn't feel strongly enough about the option to argue that it should be kept.
If anyone was actually using that option and/or runs into the problem I
mentioned, then I'll hear about it eventually.
You need to log in
before you can comment on or make changes to this bug.
Description
•