From dev-return-8591-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Sat Sep 1 21:24:34 2012
Return-Path:
X-Original-To: apmail-stdcxx-dev-archive@www.apache.org
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id EEA9FDEA3
for ; Sat, 1 Sep 2012 21:24:33 +0000 (UTC)
Received: (qmail 37597 invoked by uid 500); 1 Sep 2012 21:24:33 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 37529 invoked by uid 500); 1 Sep 2012 21:24:33 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 37520 invoked by uid 99); 1 Sep 2012 21:24:33 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Sep 2012 21:24:33 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [64.34.174.152] (HELO hates.ms) (64.34.174.152)
by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Sep 2012 21:24:26 +0000
Received: from [192.168.1.200] (cpe-069-134-011-036.nc.res.rr.com [69.134.11.36])
by hates.ms (Postfix) with ESMTPSA id 570E845C1AA
for ; Sat, 1 Sep 2012 21:24:06 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: STDCXX forks
From: Liviu Nicoara
In-Reply-To:
Date: Sat, 1 Sep 2012 17:24:06 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <06891A14-A1F4-41C5-88B0-E668370D243D@hates.ms>
References: <5040B0CD.9040407@hates.ms> <50423490.2020007@hates.ms>
To: dev@stdcxx.apache.org
X-Mailer: Apple Mail (2.1278)
X-Virus-Checked: Checked by ClamAV on apache.org
On Sep 1, 2012, at 1:52 PM, Stefan Teleman wrote:
> On Sat, Sep 1, 2012 at 12:15 PM, Liviu Nicoara wrote:
>> [...]
>> This pretty much sums up my first impression.
>
> [...]
> To begin with: the compiler flags/GNUmakefile changes are very
> specific to the SunPro compilers and to our internal build system.
> These changes are most likely not suitable for inclusion in the
> canonical stdcxx, except maybe for the sunpro.config changes, in case
> someone would like to be able to replicate our builds. I'd like to
> mention that, in Solaris, Apache stdcxx is a "system library".
Good point.
>
> About the Standard C Library forwarding header files: these changes
> are specfic to Solaris. The reason behind them is: the Solaris
> architectural rules, which can be best summarized as: "there can be
> only one of each". In other words, it is Verboten, in Solaris, to
> duplicate the Standard C Library header files (or any other header
> file for that matter). The Solaris Standard C Library header files are
> C++-clean - they are required to be so, by the same architectural
> rules. Again, these changes are specific to Solaris, and are probably
> not portable across other implementations. I know for a fact that they
> are not portable for either the GCC or Intel compilers (with which I
> test regularly on Linux, in addition to SunPro).
>
> So these two groups of changesets can be ignored.
Got it.
>
> I opened yesterday STDCXX-1066:
>
> https://issues.apache.org/jira/browse/STDCXX-1056
>
> about the pthread_mutex_t/pthread_cond_t alignment on SPARCV8. I'll
> have patches done this weekend. Achtung: the patchset is very large
> and touches a very large number of files. It's strange that I didn't
> get an email about STDCXX-1066.
Acknowledged. I have seen the individual patches on those two websites.
>
> I'd also like to talk about STDCXX-1056:
>
> https://issues.apache.org/jira/browse/STDCXX-1056
>
> which has already had an initial discussion, and for which I have
> attached a patch. This issue also addresses (indirectly) linkage when
> building with GCC. On the recent versions of GCC that I have tested
> with, passing -supc++ on link line automatically links with the GNU
> libstdc++6.so (on top of linking with stdcxx), and that just bad.
I briefly looked at it, will delve into it later.
>
> And then I'll have to cross reference the patches which refer to our
> internal bug numbers because most of them are quite old and right now,
> off the top of my head, I can't remember what they are. :-)
Thanks!
Liviu