Justin Erenkrantz wrote:
On 10/18/07, Tim Adams <[EMAIL PROTECTED]> wrote:
Has anyone heard any news about the Board vote?
The Incubator PMC vote closed too late to be included in this month's
meeting. It'll have to wait until next month's meeting. -- justin
Correction; I would have added
On 10/18/07, Tim Adams <[EMAIL PROTECTED]> wrote:
> Has anyone heard any news about the Board vote?
The Incubator PMC vote closed too late to be included in this month's
meeting. It'll have to wait until next month's meeting. -- justin
I created what I'm hoping will be the final stdcxx 4.2.0 release
candidate, stdcxx-4.2.0-rc-6:
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/
along with a tarball containing the sources:
http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.2.0.tar.gz
The MD5 sum for the
Has anyone heard any news about the Board vote?
-- Tim
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, October 16, 2007 8:55 PM
To: stdcxx-dev@incubator.apache.org
Subject: [Fwd: [VOTE RESULT] graduate stdcxx to TLP]
Orig
[
https://issues.apache.org/jira/browse/STDCXX-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-406:
Fix Version/s: (was: 4.2)
4.2.1
Unfortunately, this has to be deferred until
[
https://issues.apache.org/jira/browse/STDCXX-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor closed STDCXX-509.
---
Resolution: Fixed
We can finally close this. Whew!
See this thread for background into the final sol
[
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor reassigned STDCXX-505:
---
Assignee: Martin Sebor (was: Marc Betz)
> Update the Acknowledgments page
>
[
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor closed STDCXX-505.
---
Resolution: Fixed
Closing as fixed.
> Update the Acknowledgments page
>
William A. Rowe, Jr. wrote:
Farid Zaripov wrote:
But personally for me the version in the version info resource
would be more interesting. BTW there are more fields, i.e.
Copyright, Product Name, Company Name, Description, ...
From your answer, I presume it's no.
I don't know for 100% s
Travis Vitek wrote:
Farid Zaripov wrote:
Since the patch was stripped, I"m sending it inplace.
ChangeLog:
STDCXX-509
* limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
The _xxxBits constants defined with C++ linkage and exported
as the floating constants with the mangled na
Farid Zaripov wrote:
>
> Since the patch was stripped, I"m sending it inplace.
>
> ChangeLog:
> STDCXX-509
> * limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
> The _xxxBits constants defined with C++ linkage and exported
> as the floating constants with the mangled names for
Farid Zaripov wrote:
But personally for me the version in the version info resource
would be more interesting. BTW there are more fields, i.e.
Copyright, Product Name, Company Name, Description, ...
From your answer, I presume it's no.
http://svn.apache.org/repos/asf/apr/apr/trunk/libapr.r
> The patch is attached.
Since the patch was stripped, I"m sending it inplace.
ChangeLog:
STDCXX-509
* limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
The _xxxBits constants defined with C++ linkage and exported as the floating
constants with the mangled names for the bi
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Пт, 19.10.2007 1:58
> To: stdcxx-dev@incubator.apache.org
> Subject: /VERSION linker option on Windows
>
> Are we making use of it? If not, should we be?
>
>http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx
Why not? :)
Farid, I'm afraid your patch got stripped -- can you try again,
maybe inline?
Martin
Farid Zaripov wrote:
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Пт, 19.10.2007 0:35
To: stdcxx-dev@incubator.apache.org
Subject: Re: binary compatibility question
[...]
So what would we do in the
Martin Sebor wrote:
Are we making use of it? If not, should we be?
http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx
It's not terribly interesting.
You really want to focus on the VERSIONINFO member of the library's dll
resource,
which provides a whole lot more meaningful infor
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Пт, 19.10.2007 0:35
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: binary compatibility question
>
[...]
> So what would we do in the archive? Keep the incompatible extern "C" symbol?
Yes. Actually in shared library will be prese
Are we making use of it? If not, should we be?
http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx
Martin
Martin Sebor wrote:
Travis Vitek wrote:
Martin,
That patch won't work. The _C_grow needs to be made private. It was
private in 4.1.3, but is public in 4.2. IMO it should always be private
and it was an oversight that under some conditions it could be made
public.
I have tested the following pa
Farid Zaripov wrote:
The binary compatibility requirement is related to shared libraries only,
or to both shared and static libraries?
Both.
When the user builds their own shared library, libusr.so, from
the stdcxx archive, libstd.a, (a subset of) stdcxx symbols become
part of the interface
Travis Vitek wrote:
Martin Sebor wrote:
Farid Zaripov wrote:
From: Travis Vitek wrote:
That is fine.
2007-10-18 Travis Vitek <[EMAIL PROTECTED]>
* _config-msvc.h [_RWSTD_VER_MAJOR]: Define configuration
macros to enable binary compatibility with 4.1.3 on MSVC.
I thi
> От: Travis Vitek [mailto:[EMAIL PROTECTED]
> Отправлено: Пт, 19.10.2007 0:07
> Кому: stdcxx-dev@incubator.apache.org
> Тема: RE: binary compatibility question
>
> Farid Zaripov wrote:
> >
> > The binary compatibility requirement is related to shared
> >libraries only, or to both shared and stat
Martin Sebor wrote:
>
>Farid Zaripov wrote:
>>>
>>> From: Travis Vitek wrote:
>>>
>>> That is fine.
>>>
>>>
>>> 2007-10-18 Travis Vitek <[EMAIL PROTECTED]>
>>>
>>> * _config-msvc.h [_RWSTD_VER_MAJOR]: Define configuration
>>> macros to enable binary compatibility with 4.1.3 on
Farid Zaripov wrote:
>
> The binary compatibility requirement is related to shared
>libraries only, or to both shared and static libraries?
>
Well technically it is a problem with both static and shared, but for it
to be an issue with a static build the user would have to have kept
their obje
Farid Zaripov wrote:
From: Travis Vitek [mailto:[EMAIL PROTECTED]
Sent: Чт, 18.10.2007 22:59
To: stdcxx-dev@incubator.apache.org
Subject: RE: status of fix for incompatibilities in exception classes on Windows
That is fine.
2007-10-18 Travis Vitek <[EMAIL PROTECTED]>
* _config-msvc.
Martin Sebor wrote:
>Travis Vitek wrote:
>> Martin Sebor wrote:
>>> Travis, while testing your updated patch, I wonder if it would be
>>> possible to quickly and easily fix STDCXX-509 even for MSVC in
>>> a binary compatible way by using #pragma init_seg to initialize
>>> the constants before an
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Чт, 18.10.2007 22:59
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: status of fix for incompatibilities in exception classes on
> Windows
>
> That is fine.
>
>
> 2007-10-18 Travis Vitek <[EMAIL PROTECTED]>
>
> * _config-msv
>Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Travis Vitek wrote:
>>> I totally forgot about it after scrambling to get the other
>>> patch made last night. I'll post a patch for review ASAP.
>>>
>>>
>>> Martin Sebor wrote:
What is the status of the patch for the unsats for the exc
Travis Vitek wrote:
Travis Vitek wrote:
I totally forgot about it after scrambling to get the other patch made
last night. I'll post a patch for review ASAP.
Martin Sebor wrote:
What is the status of the patch for the unsats for the exception
classes on Windows? Anyone working on it? Farid
Martin Sebor wrote:
I've repeated the same test with both the library as well as
the examples built with MSVC 7.1. The results are a lot better,
although I still see an unsat for the exception copy ctor (as
in the previous case):
EXAMPLE
ifstream.exe: exception::exception(const execept
I've repeated the same test with both the library as well as
the examples built with MSVC 7.1. The results are a lot better,
although I still see an unsat for the exception copy ctor (as
in the previous case):
EXAMPLE
ifstream.exe: exception::exception(const exeception&)
I suspect the
Travis Vitek wrote:
Martin Sebor wrote:
Travis, while testing your updated patch, I wonder if it would be
possible to quickly and easily fix STDCXX-509 even for MSVC in
a binary compatible way by using #pragma init_seg to initialize
the constants before any user-defined objects?
http://msdn2.mi
Travis Vitek wrote:
>
>I totally forgot about it after scrambling to get the other patch made
>last night. I'll post a patch for review ASAP.
>
>
>Martin Sebor wrote:
>>
>>What is the status of the patch for the unsats for the exception
>>classes on Windows? Anyone working on it? Farid? Travis?
>Martin Sebor wrote:
>
>While testing the patch for the missing exception symbols I'm
>running into a few other unsats that I haven't seen mentioned
>before. I'm not sure if it's relevant yet but I'm linking
>stdcxx 4.2.0 15d DLL built with MSVC 8.0 into 4.1.3 examples
>built with MSVC 7.1 (also
Farid Zaripov wrote:
>
>> -Original Message-
>> From: Martin Sebor [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 18, 2007 5:43 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] __rw_dbl_infinity ABI change with MSVC
>>
>> Thanks!
>>
>> Farid, does this patch loo
Martin Sebor wrote:
>
>Travis, while testing your updated patch, I wonder if it would be
>possible to quickly and easily fix STDCXX-509 even for MSVC in
>a binary compatible way by using #pragma init_seg to initialize
>the constants before any user-defined objects?
>
>http://msdn2.microsoft.com/en-
Martin Sebor wrote:
>
>Any ideas?
Not at the moment.
>
>[*] Btw., how do I demangle MSVC symbols? (I checked dumpbin
>help but I don't see any obvious option).
undname.exe
>
>Martin
>
While testing the patch for the missing exception symbols I'm
running into a few other unsats that I haven't seen mentioned
before. I'm not sure if it's relevant yet but I'm linking
stdcxx 4.2.0 15d DLL built with MSVC 8.0 into 4.1.3 examples
built with MSVC 7.1 (also 15d).
EXAMPLE
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 18, 2007 7:23 PM
> To: Farid Zaripov
> Subject: [Fwd: RE: STDCXX-509]
>
> Hi Farid,
>
> It's important that we all understand what's going on. I
> haven't seen your response to Travis' post on
Farid Zaripov wrote:
-Original Message-
From: Travis Vitek [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 7:24 PM
To: stdcxx-dev@incubator.apache.org
Subject: RE: status of fix for incompatibilities in exception
classes on Windows
I totally forgot about it after scrambli
Travis, while testing your updated patch, I wonder if it would be
possible to quickly and easily fix STDCXX-509 even for MSVC in
a binary compatible way by using #pragma init_seg to initialize
the constants before any user-defined objects?
http://msdn2.microsoft.com/en-us/library/7977wcck(VS.71).
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 18, 2007 7:24 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: status of fix for incompatibilities in exception
> classes on Windows
>
>
> I totally forgot about it after scrambling to g
Travis Vitek wrote:
I totally forgot about it after scrambling to get the other patch made
last night. I'll post a patch for review ASAP.
I'm testing it with MSVC 8.0 right now, but if you could double
heck it in your environment as well, perhaps with a different
version of the compiler (and/or
I totally forgot about it after scrambling to get the other patch made
last night. I'll post a patch for review ASAP.
>-Original Message-
>From: Martin Sebor [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 18, 2007 8:50 AM
>To: stdcxx-dev@incubator.apache.org
>Subject: status of fix
This is in, both on 4.2.0 and trunk:
http://svn.apache.org/viewvc?rev=586016&view=rev
http://svn.apache.org/viewvc?rev=586017&view=rev
Martin Sebor wrote:
Martin Sebor wrote:
This patch attempts to fix the binary incompatibility of __rw_facet
ctor and dtor when compiled with MSVC on Window
What is the status of the patch for the unsats for the exception
classes on Windows? Anyone working on it? Farid? Travis?
Martin
[
https://issues.apache.org/jira/browse/STDCXX-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535937
]
Martin Sebor commented on STDCXX-162:
-
As noted in the following thread:
http://www.nabble.com/stdcxx-4.2.0-4.1.3
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 18, 2007 5:43 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] __rw_dbl_infinity ABI change with MSVC
>
> Thanks!
>
> Farid, does this patch look okay to you?
The patch looks g
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 18, 2007 5:38 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] std::string::_C_grow() 4.2 incompatibility
>
> I'm getting ready to commit the original patch -- Travis, do
> you ag
Martin Sebor wrote:
This patch attempts to fix the binary incompatibility of __rw_facet
ctor and dtor when compiled with MSVC on Windows, introduced while
fixing STDCXX-469 (MSVC mangles the access specifier into the names
of class members):
https://issues.apache.org/jira/browse/STDCXX-469
I
Thanks!
Farid, does this patch look okay to you?
Travis, please double-check the patch for missing whitespace
and post a ChangeLog entry. Unless there are objections from
Farid or anyone else, I'll go ahead and commit it as soon as
I get it.
Martin
Travis Vitek wrote:
This patch attempts to f
Okay, unless I hear further objections in the next 10 minutes
or so this is going in.
Martin
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
The only thing I don't like about this patch is that it
assumes no other platform will exhibit the same behavior
that we are seeing on
I'm getting ready to commit the original patch -- Travis,
do you agree? Farid, any concerns or comments with it?
Martin
Martin Sebor wrote:
Travis Vitek wrote:
Martin,
That patch won't work. The _C_grow needs to be made private. It was
private in 4.1.3, but is public in 4.2. IMO it should alw
53 matches
Mail list logo
