public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Phil Edwards <phil@jaj.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c++/5821: Solaris: C++ compiler defines _XOPEN_SOURCE
Date: Tue, 05 Mar 2002 13:56:00 -0000	[thread overview]
Message-ID: <20020305215601.24143.qmail@sources.redhat.com> (raw)

The following reply was made to PR c++/5821; it has been noted by GNATS.

From: Phil Edwards <phil@jaj.com>
To: Dimitri Papadopoulos <dpo@club-internet.fr>
Cc: rodrigc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/5821: Solaris: C++ compiler defines _XOPEN_SOURCE
Date: Tue, 5 Mar 2002 16:52:00 -0500

 On Mon, Mar 04, 2002 at 11:55:31PM +0100, Dimitri Papadopoulos wrote:
 > > It's not "practical".  It's "required".  As in, if it's not defined,
 > > nothing works.
 > 
 > As I said if libstdc++ requires _XOPEN_SOURCE just
 > define it when building libstdc++. But then maybe
 > it's required by libstdc++ headers made available to
 > end-users. In that case I do understand the problem
 > better. But it still can be worked around by writing
 > wrappers or modifying headers appropriately. Then
 > maybe it's still something else: in that case please
 > someone explain me. I have good knowledge of Solaris
 > and I may help to remove the need for _XOPEN_SOURCE.
 
 Large parts of the C++ standard library are actually defined in the header
 files (until the compiler supports 'export'), so maintainer build-time
 details are often also end-user compile-time details.
 
 
 > Finally if your concern is 64-bit targets, then you
 > need to define 
 > 	-xarch=v9 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
 > as documented in the solaris documentation, but still,
 > the Solaris environment leaves it to the user to define
 > these variables.
 
 This would be handled by the compiler config files for 64-bit Solaris.
 
 
 > > This has been discussed to death on the mailing lists.  See the archives
 > > before resubmitting the same bug report.
 > 
 > This bug report was not in the archives when this bug was
 > reported.
 
 I may have confused you with one of the other reporters.  If I did,
 I apologize.
 
 > And in any case searching the archive gives:
 > 	No matches were found for '_xopen_source and solaris'.
 > Consider fixing the search engine first...
 
 Eh?  I get 72 matches for both terms, and 234 matches for _XOPEN_SOURCE
 alone.
 
 
 > I do understand you have limited time, and I do appreciate
 > your efforts to bring out a free compiler. But maybe someone
 > could have told me this was discussed in the mailing lists
 > and given a short explanation (something better than "It's
 > not practical.  It's required." which is supposed to make
 > me feel like an idiot because I don't understand what other
 > oh so brilliant people understand).
 > 
 > I've been chasing bugs in GCC for some years (few bugs maybe,
 > but still) and would have expected a different tone in your
 
 I apologize for my tone.  The _XOPEN_SOURCE kludge -- and yes, it is a
 kludge, we would like to replace it with something better -- keeps getting
 brought up over and over by people who simply assert that it's easy to
 "fix" without ever actually demonstrating how.  After a while it becomes
 bothersome.
 
 I think I'll add this to the libstdc++ FAQ, and provide a link to the
 mailing list archives.
 
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams


             reply	other threads:[~2002-03-05 21:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-05 13:56 Phil Edwards [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-03-04 14:56 Dimitri Papadopoulos
2002-03-04  7:46 Phil Edwards
2002-03-03 15:03 rodrigc
2002-03-03 14:56 dpo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020305215601.24143.qmail@sources.redhat.com \
    --to=phil@jaj.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).