Closed Bug 81031 Opened 23 years ago Closed 23 years ago

NSPR configure script passes -pipe unconditionally

Categories

(NSPR :: NSPR, defect, P3)

4.0.2
x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jim_nance, Assigned: cls)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
OS: Windows NT → Linux
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.
Blocks: 81087
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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
Silly bugzilla. Taking back.
Assignee: wtc → cls
is this in? if not, is there a reason why?
Other priorities. I have an updated patch in my tree that I need to update though.
Attached patch Updated version (deleted) — Splinter Review
Attachment #40830 - Attachment is obsolete: true
Patch has been checked into the tip & the NSPRPUB_PRE_4_2_CLIENT_BRANCH .
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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+
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 → ---
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.
The --disable-gcc-pipe configure option has been removed.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: