You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Mladen Turk <mt...@apache.org> on 2006/09/05 19:12:39 UTC
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Branko Čibej wrote:
> Mladen Turk wrote:
>>>
>>
>> MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections
>> found with different attributes (40400040)
>> MSVCRTD.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C0000040)
>> merged into '.rdata' (40000040) with different attributes
>>
>> ... and it doesn't work although builds with warnings.
>> I have contacted Jac to see if he has some ideas why this
>> doesn't work on non x86 CPU's, but I'm skeptic because those
>> link warning says that for AMD64 those segments are read only,
>> and thus you can not insert your own handler.
>
> I know that boost_thread uses this method, and I've verified that it
> works on AMD64 and IA64; the tric is, I believe, that Boost inserts a
> single static handler into the static constructor and destructor
> segments, and lets that handler maintain its own list of hooks.
>
Are you sure this works in native, or only on x86 emulated
mode on those processors?
I have tried almost everything, but since link says it
is a read-only thing on those CPU's I'm stuck.
Since all this is a hack, IMHO we can simply exploit the
feature from DLL apr build, and leave the current
status for LIB builds like it was before.
(BTW, my patch does that).
Regards,
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>
>> Mladen Turk wrote:
>>
>>> Since all this is a hack, IMHO we can simply exploit the
>>> feature from DLL apr build, and leave the current
>>> status for LIB builds like it was before.
>>> (BTW, my patch does that).
>>>
>> Given the choice between supporting all architectures except amd64, or
>> supporting only .dll's, I vote for the former. That's -1 to the code
>> living in trunk.
>>
>> The DLL thing is a 'hack' - something that doesn't solve the whole issue
>> but works around the problem in front of you. The CRT linkage is by design
>> in the PE format, the only hacks needed are to resolve why certain PE flavors
>> are being handled differently than others, and writing the #if arch logic
>> to handle this or leave it unresolved for an architecture.
>>
>> Native-64 is going to seriously underperform 32 bit compilations for 95% of
>> applications in the first place. But it's entirely reasonable (and common)
>> for developers to decide to roll out a monolithic .exe binary.
>>
>
> One more thought on the Native-64 issue; this is SUPPOSED to be supported by
> the Windows PE format. Either we did something wrong or it's a bug in the
> compiler (and since they are soliciting feedback for SP1 it's a good thing to
> point out, I'll see if we can't fast track it.)
>
> But my point is that the THREAD_DETACH solution covers 1/2 the cases, and the
> PE solution solves 100% of the cases, sans bugs.
>
>
>> Other opinions before Mladen or I proceed?
>>
>
> I'm not happy with the silence here... feedback please?
>
Sorry ... busybusybusy ... but I agree with you that this should work.
> There's another issue - we've been debating a 'fix' without any test case, and
> really can't have a code shootout without some test case in place that validates
> the two possible solutions.
>
And I just can't help here right now. No time to breathe.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>
>> Mladen Turk wrote:
>>
>>> Since all this is a hack, IMHO we can simply exploit the
>>> feature from DLL apr build, and leave the current
>>> status for LIB builds like it was before.
>>> (BTW, my patch does that).
>>>
>> Given the choice between supporting all architectures except amd64, or
>> supporting only .dll's, I vote for the former. That's -1 to the code
>> living in trunk.
>>
>> The DLL thing is a 'hack' - something that doesn't solve the whole issue
>> but works around the problem in front of you. The CRT linkage is by design
>> in the PE format, the only hacks needed are to resolve why certain PE flavors
>> are being handled differently than others, and writing the #if arch logic
>> to handle this or leave it unresolved for an architecture.
>>
>> Native-64 is going to seriously underperform 32 bit compilations for 95% of
>> applications in the first place. But it's entirely reasonable (and common)
>> for developers to decide to roll out a monolithic .exe binary.
>>
>
> One more thought on the Native-64 issue; this is SUPPOSED to be supported by
> the Windows PE format. Either we did something wrong or it's a bug in the
> compiler (and since they are soliciting feedback for SP1 it's a good thing to
> point out, I'll see if we can't fast track it.)
>
> But my point is that the THREAD_DETACH solution covers 1/2 the cases, and the
> PE solution solves 100% of the cases, sans bugs.
>
>
>> Other opinions before Mladen or I proceed?
>>
>
> I'm not happy with the silence here... feedback please?
>
Sorry ... busybusybusy ... but I agree with you that this should work.
> There's another issue - we've been debating a 'fix' without any test case, and
> really can't have a code shootout without some test case in place that validates
> the two possible solutions.
>
And I just can't help here right now. No time to breathe.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Nov 20, 2006 at 02:30:33PM -0600, William A. Rowe, Jr. wrote:
> > Other opinions before Mladen or I proceed?
>
> I'm not happy with the silence here... feedback please?
Considering that this commit busted Subversion on Win32 and other conceptual
arguments against this change (which I'm admittedly not the best judge of - but
when OtherBill and Brane agree, I'm sure it's right), so +1 for reverting this
commit. -- justin
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Since all this is a hack, IMHO we can simply exploit the
>> feature from DLL apr build, and leave the current
>> status for LIB builds like it was before.
>> (BTW, my patch does that).
>
> Given the choice between supporting all architectures except amd64, or
> supporting only .dll's, I vote for the former. That's -1 to the code
> living in trunk.
>
> The DLL thing is a 'hack' - something that doesn't solve the whole issue
> but works around the problem in front of you. The CRT linkage is by design
> in the PE format, the only hacks needed are to resolve why certain PE flavors
> are being handled differently than others, and writing the #if arch logic
> to handle this or leave it unresolved for an architecture.
>
> Native-64 is going to seriously underperform 32 bit compilations for 95% of
> applications in the first place. But it's entirely reasonable (and common)
> for developers to decide to roll out a monolithic .exe binary.
One more thought on the Native-64 issue; this is SUPPOSED to be supported by
the Windows PE format. Either we did something wrong or it's a bug in the
compiler (and since they are soliciting feedback for SP1 it's a good thing to
point out, I'll see if we can't fast track it.)
But my point is that the THREAD_DETACH solution covers 1/2 the cases, and the
PE solution solves 100% of the cases, sans bugs.
> Other opinions before Mladen or I proceed?
I'm not happy with the silence here... feedback please?
There's another issue - we've been debating a 'fix' without any test case, and
really can't have a code shootout without some test case in place that validates
the two possible solutions.
Bill
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Since all this is a hack, IMHO we can simply exploit the
>> feature from DLL apr build, and leave the current
>> status for LIB builds like it was before.
>> (BTW, my patch does that).
>
> Given the choice between supporting all architectures except amd64, or
> supporting only .dll's, I vote for the former. That's -1 to the code
> living in trunk.
>
> The DLL thing is a 'hack' - something that doesn't solve the whole issue
> but works around the problem in front of you. The CRT linkage is by design
> in the PE format, the only hacks needed are to resolve why certain PE flavors
> are being handled differently than others, and writing the #if arch logic
> to handle this or leave it unresolved for an architecture.
>
> Native-64 is going to seriously underperform 32 bit compilations for 95% of
> applications in the first place. But it's entirely reasonable (and common)
> for developers to decide to roll out a monolithic .exe binary.
One more thought on the Native-64 issue; this is SUPPOSED to be supported by
the Windows PE format. Either we did something wrong or it's a bug in the
compiler (and since they are soliciting feedback for SP1 it's a good thing to
point out, I'll see if we can't fast track it.)
But my point is that the THREAD_DETACH solution covers 1/2 the cases, and the
PE solution solves 100% of the cases, sans bugs.
> Other opinions before Mladen or I proceed?
I'm not happy with the silence here... feedback please?
There's another issue - we've been debating a 'fix' without any test case, and
really can't have a code shootout without some test case in place that validates
the two possible solutions.
Bill
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Since all this is a hack, IMHO we can simply exploit the
> feature from DLL apr build, and leave the current
> status for LIB builds like it was before.
> (BTW, my patch does that).
Given the choice between supporting all architectures except amd64, or
supporting only .dll's, I vote for the former. That's -1 to the code
living in trunk.
The DLL thing is a 'hack' - something that doesn't solve the whole issue
but works around the problem in front of you. The CRT linkage is by design
in the PE format, the only hacks needed are to resolve why certain PE flavors
are being handled differently than others, and writing the #if arch logic
to handle this or leave it unresolved for an architecture.
Native-64 is going to seriously underperform 32 bit compilations for 95% of
applications in the first place. But it's entirely reasonable (and common)
for developers to decide to roll out a monolithic .exe binary.
Other opinions before Mladen or I proceed?
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Since all this is a hack, IMHO we can simply exploit the
> feature from DLL apr build, and leave the current
> status for LIB builds like it was before.
> (BTW, my patch does that).
Given the choice between supporting all architectures except amd64, or
supporting only .dll's, I vote for the former. That's -1 to the code
living in trunk.
The DLL thing is a 'hack' - something that doesn't solve the whole issue
but works around the problem in front of you. The CRT linkage is by design
in the PE format, the only hacks needed are to resolve why certain PE flavors
are being handled differently than others, and writing the #if arch logic
to handle this or leave it unresolved for an architecture.
Native-64 is going to seriously underperform 32 bit compilations for 95% of
applications in the first place. But it's entirely reasonable (and common)
for developers to decide to roll out a monolithic .exe binary.
Other opinions before Mladen or I proceed?
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
>
> P.S.: IM(ANAL)HO looking at this Boost-licensed code won't taint APR,
> but I may be wrong.
You are right, but you cannot abridge the license;
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
Mladen Turk wrote:
> Branko Čibej wrote:
>>
>> Here's the code. This is the tss_pe.cpp file from Boost, slightly
>> modified (lines 35--37) in order to compile on Win/IA64. It compiles
>> and runs on x86, AMD64 and IA64, but I only ever tested it as a
>> static library.
>
> Can you send some example of its usage?
> Just send me the binary that works on WIN64/amd64 with that.
Sorry, I definitely no longer have access to that.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
Branko Čibej wrote:
>
> Here's the code. This is the tss_pe.cpp file from Boost, slightly
> modified (lines 35--37) in order to compile on Win/IA64. It compiles and
> runs on x86, AMD64 and IA64, but I only ever tested it as a static
> library.
Can you send some example of its usage?
Just send me the binary that works on WIN64/amd64 with that.
> It's also C++, and quite possible that the same method won't
> work in C.
Right, APR is C code, but I doubt that's the reason because the
same thing works on x86 with the same compiler (Vs2005).
It even works with VC6 on x86, so I suppose its either CPU or
WIN32/WIN64 related.
Regards,
Mladen
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/10/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Thanks Branko - and Mladen - I'm studying the code, Mladen's interpretation
> for threadpriv.c and compilation on vc 6.0, 2002, 2003 and 2005 flavor VS's
> to determine if this is the best solution, and should be ready to comment
> more tomorrow.
>
> I'm especially interested in the emits Mladen later reported which I'll work
> on diagnosing and explaining. It might take a bit of reverse engineering.
I don't really know the root cause, but this whole set of changes
borks Subversion when it tries to terminate with VS 2005.
As best as I can determine, the calling sequence is:
1) svn.exe's main() function exits normally
2) apr_terminate() gets invoked
3) threadkey_terminate() is called
4) APR's DllMain() is called with DLL_THREAD_DETACH
5) threadkey_detach() is called
6) apr_hash_first() is called with an invalid pointer
threadkey_detach() segfaults because it tries to access memory that
was freed in apr_terminate().
I've managed to resolve this locally by the patch below. Does this
make sense? -- justin
Index: misc/win32/start.c
===================================================================
--- misc/win32/start.c (revision 464264)
+++ misc/win32/start.c (working copy)
@@ -253,7 +253,9 @@
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
- threadkey_detach();
+ if (initialized) {
+ threadkey_detach();
+ }
break;
case DLL_PROCESS_DETACH:
break;
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
> William A. Rowe, Jr. wrote:
>> Branko Čibej wrote:
>>
>>> FYI, I'm waiting for someone to send me the code that I'd made work on
>>> Win64. In restrospect, it's quite possible that I only fixed it for the
>>> static-link case -- DLLs do have their own ctor/dtor segments, but I'm
>>> not sure that they're noticed at program shutdown or library close.
>>>
>>> I'll know more in a few days.
>>>
>>
>> That sounds great - we'll be patient :) But there is the thought of
>> doing a release at the end of the week, so once you do hear word, let us know.
You note I've sort of let the new tarballs slip a bit, I don't like the
idea of rapid-firing alot more 0.9 releases (hopefully someday soon it will
be mostly static.)
I've been holding out to look at this issue, and the issue of mac filename
case-canonicalization.
>> If your solution works only for static-links, and Mladen's works for
>> the .dll case, then it seems we could mix n match to solve the whole issue.
The more I think about it, the more that the 64bit AMD seems like the
exception to solve, not static-links. Let's proceed on this path, and
then pick up the 64 bit compilation issues as a second phase.
Frankly 0.9 really wasn't 64P ready (while 64LP or 64ILP models compiled
fine). So backporting -this- fix to 0.9 and ignoring the 64amd issues
doesn't bother me at all for 0.9. For 1.2 / 1.3 it would be nice to solve
every case.
> Here's the code. This is the tss_pe.cpp file from Boost, slightly
> modified (lines 35--37) in order to compile on Win/IA64. It compiles and
> runs on x86, AMD64 and IA64, but I only ever tested it as a static
> library. It's also C++, and quite possible that the same method won't
> work in C.
Thanks Branko - and Mladen - I'm studying the code, Mladen's interpretation
for threadpriv.c and compilation on vc 6.0, 2002, 2003 and 2005 flavor VS's
to determine if this is the best solution, and should be ready to comment
more tomorrow.
I'm especially interested in the emits Mladen later reported which I'll work
on diagnosing and explaining. It might take a bit of reverse engineering.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Greg Marr wrote:
> At 05:44 PM 9/15/2006, William A. Rowe, Jr. wrote:
>> It seems, then, that this will become one of two different solutions,
>> with your DllMain alternative implementation that will need to be
>> compiled
>> if we discover we are building to a dynamic library for non-x86
>> targets :(
>>
>> Perhaps VC8 actually has a solution, I can revisit since it's not
>> unreasonable
>> to demand the modern compiler as a minimum baseline for modern CPU's.
>
> Isn't VC8 required for non-x86 anyway?
That's my theory, but I haven't dissected the internals of the CRT for 8
just yet. And relying on internals can always be a dicey thing if there
isn't a track record to point to.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES
include/arch/win32/apr_arch_threadproc.h misc/win32/start.c
threadproc/win32/threadpriv.c
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 05:44 PM 9/15/2006, William A. Rowe, Jr. wrote:
>It seems, then, that this will become one of two different solutions,
>with your DllMain alternative implementation that will need to be
>compiled
>if we discover we are building to a dynamic library for non-x86
>targets :(
>
>Perhaps VC8 actually has a solution, I can revisit since it's not
>unreasonable
>to demand the modern compiler as a minimum baseline for modern CPU's.
Isn't VC8 required for non-x86 anyway?
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
> Adding any of the '#pragma data_seg'
> gives the following compile time warning for static
> APR compiled for a simple hello-world.c:
>
> MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections
> found with different attributes (40400040)
> MSVCRTD.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C0000040)
> merged into '.rdata' (40000040) with different attributes
>
> Build with:
> Microsoft Visual Studio 2005, Version 2.0.50727
> Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42 for x64
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> I'm really feeling stupid here. You are saying it works,
> but I've spend more then 20 working hours, and I can not make
> it even to compile without warnings.
It seems, then, that this will become one of two different solutions,
with your DllMain alternative implementation that will need to be compiled
if we discover we are building to a dynamic library for non-x86 targets :(
I spend a good part of the day deep in Win32 debugging and internals, and
stopped to visit our friend the CRT. There is definitely nothing to help
us there, in terms of internals, that is portable across VC6 ... VC8.
Perhaps VC8 actually has a solution, I can revisit since it's not unreasonable
to demand the modern compiler as a minimum baseline for modern CPU's.
Bill
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Adding any of the '#pragma data_seg'
>> gives the following compile time warning for static
>> APR compiled for a simple hello-world.c:
>>
>> MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections
>> found with different attributes (40400040)
>> MSVCRTD.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C0000040)
>> merged into '.rdata' (40000040) with different attributes
>>
>> Build with:
>> Microsoft Visual Studio 2005, Version 2.0.50727
>
> Quick observation, but MSVCRTD.lib in combination with VS 2005?
>
> If you compile with the appropriate runtime what happens?
>
Well, I'm compiling with the DLL version of MSVCRT
either as /MDd or /MD.
For Release build the linker warning is:
Linking...
MSVCRT.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections found with different attributes (40400040)
MSVCRT.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C0000040) merged into '.rdata' (40000040) with different attributes
Regards,
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Greg Marr wrote:
> At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
>> Quick observation, but MSVCRTD.lib in combination with VS 2005?
>
> Yes, the lib file does not have the version number in the filename.
Yup - that's what I just verified and my original misassumption :)
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES
include/arch/win32/apr_arch_threadproc.h misc/win32/start.c
threadproc/win32/threadpriv.c
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 02:00 PM 9/15/2006, Mladen Turk wrote:
>Greg Marr wrote:
>>At 12:59 PM 9/15/2006, Mladen Turk wrote:
>>>Greg Marr wrote:
>>>>At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
>>>>>Quick observation, but MSVCRTD.lib in combination with VS 2005?
>>>>Yes, the lib file does not have the version number in the filename.
>>>
>>>???
>>>What are you talking about?
>>The DLL for VS 2003 is MSVCRT71d.dll, but the lib file is
>>MSVCRTd.lib.
>>The DLL for VS 2005 is MSVCRT80d.dll, but the lib file is
>>MSVCRTd.lib.
>>This way, the user doesn't have to change their project settings or
>>pragmas when moving from one version to the next.
>
>Right. So what?
>Still don't get how is that related to the problem?
It's not. I was explaining to Bill why you were linking against
MSVCRTd.lib when compiling in VS 2005.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
Greg Marr wrote:
> At 12:59 PM 9/15/2006, Mladen Turk wrote:
>> Greg Marr wrote:
>>> At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
>>>> Quick observation, but MSVCRTD.lib in combination with VS 2005?
>>> Yes, the lib file does not have the version number in the filename.
>>
>> ???
>> What are you talking about?
>
> The DLL for VS 2003 is MSVCRT71d.dll, but the lib file is MSVCRTd.lib.
>
> The DLL for VS 2005 is MSVCRT80d.dll, but the lib file is MSVCRTd.lib.
>
> This way, the user doesn't have to change their project settings or
> pragmas when moving from one version to the next.
>
Right. So what?
Still don't get how is that related to the problem?
Since I use VS2005, the final exe will be linked with
MSVCRT80*.dll. The same is in place on Win32/x86
(same code, same compiler).
Is it so hard to understand that the same code,
with the same compiler on WIN64/x64 does not work,
while it works on WIN32/x86?
So:
VC6/x86 lib,dll works
VS2005/x86 lib,dll works
VS2005/x64 creates the linker warnings I noted, and it doesn't work.
Regards,
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES
include/arch/win32/apr_arch_threadproc.h misc/win32/start.c
threadproc/win32/threadpriv.c
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 12:59 PM 9/15/2006, Mladen Turk wrote:
>Greg Marr wrote:
>>At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
>>>Quick observation, but MSVCRTD.lib in combination with VS 2005?
>>Yes, the lib file does not have the version number in the filename.
>
>???
>What are you talking about?
The DLL for VS 2003 is MSVCRT71d.dll, but the lib file is MSVCRTd.lib.
The DLL for VS 2005 is MSVCRT80d.dll, but the lib file is MSVCRTd.lib.
This way, the user doesn't have to change their project settings or
pragmas when moving from one version to the next.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
Greg Marr wrote:
> At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
>> Quick observation, but MSVCRTD.lib in combination with VS 2005?
>
> Yes, the lib file does not have the version number in the filename.
>
???
What are you talking about?
--
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES
include/arch/win32/apr_arch_threadproc.h misc/win32/start.c
threadproc/win32/threadpriv.c
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 12:06 PM 9/15/2006, William A. Rowe, Jr. wrote:
>Quick observation, but MSVCRTD.lib in combination with VS 2005?
Yes, the lib file does not have the version number in the filename.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Adding any of the '#pragma data_seg'
> gives the following compile time warning for static
> APR compiled for a simple hello-world.c:
>
> MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections
> found with different attributes (40400040)
> MSVCRTD.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C0000040)
> merged into '.rdata' (40000040) with different attributes
>
> Build with:
> Microsoft Visual Studio 2005, Version 2.0.50727
Quick observation, but MSVCRTD.lib in combination with VS 2005?
If you compile with the appropriate runtime what happens?
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
Branko Čibej wrote:
> William A. Rowe, Jr. wrote:
>> Branko Čibej wrote:
I'm attaching the threadpriv.c
Adding any of the '#pragma data_seg'
gives the following compile time warning for static
APR compiled for a simple hello-world.c:
MSVCRTD.lib(crtexe.obj) : warning LNK4078: multiple '.CRT' sections found with different attributes (40400040)
MSVCRTD.lib(cinitexe.obj) : warning LNK4254: section '.CRT' (C0000040) merged into '.rdata' (40000040) with different attributes
Build with:
Microsoft Visual Studio 2005, Version 2.0.50727
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
On:
Microsoft Windows Server 2003 R2
Standard x64 Edition
Service Pack 1
The same code works on x86 (Windows XP/32) with either static or
dll flavor of APR.
Attached the source code...
I'm really feeling stupid here. You are saying it works,
but I've spend more then 20 working hours, and I can not make
it even to compile without warnings.
--
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
> Branko Čibej wrote:
>
>> FYI, I'm waiting for someone to send me the code that I'd made work on
>> Win64. In restrospect, it's quite possible that I only fixed it for the
>> static-link case -- DLLs do have their own ctor/dtor segments, but I'm
>> not sure that they're noticed at program shutdown or library close.
>>
>> I'll know more in a few days.
>>
>
> That sounds great - we'll be patient :) But there is the thought of doing
> a release at the end of the week, so once you do hear word, let us know.
>
> If your solution works only for static-links, and Mladen's works for the .dll
> case, then it seems we could mix n match to solve the whole issue.
>
Here's the code. This is the tss_pe.cpp file from Boost, slightly
modified (lines 35--37) in order to compile on Win/IA64. It compiles and
runs on x86, AMD64 and IA64, but I only ever tested it as a static
library. It's also C++, and quite possible that the same method won't
work in C.
Hope this helps, and sorry I don't have more time to try to solve it.
P.S.: IM(ANAL)HO looking at this Boost-licensed code won't taint APR,
but I may be wrong.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
>
> FYI, I'm waiting for someone to send me the code that I'd made work on
> Win64. In restrospect, it's quite possible that I only fixed it for the
> static-link case -- DLLs do have their own ctor/dtor segments, but I'm
> not sure that they're noticed at program shutdown or library close.
>
> I'll know more in a few days.
That sounds great - we'll be patient :) But there is the thought of doing
a release at the end of the week, so once you do hear word, let us know.
If your solution works only for static-links, and Mladen's works for the .dll
case, then it seems we could mix n match to solve the whole issue.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>
>> Do not understand why are you against such a solution.
>> The half-way is IMHO always better then no-way :)
>>
>
> Half-assed means that users rely on the design paradigm, only to discover
> later that it isn't portable.
>
> Part of the flaw was that this should have been noticed by the person who
> implemented the API on the Win32 platform with an obervation that it wasn't
> portable.
>
> Then one of three things happen, we choose not to implement it, we choose
> to implement with a #define that warns the user the pattern isn't portable
> or available in the current compilation, or we return ENOTIMPL to warn them
> at run time it's not available.
>
> You aren't solving the problem of helping users write portable code, which
> is the reason for my ongoing objection.
>
FYI, I'm waiting for someone to send me the code that I'd made work on
Win64. In restrospect, it's quite possible that I only fixed it for the
static-link case -- DLLs do have their own ctor/dtor segments, but I'm
not sure that they're noticed at program shutdown or library close.
I'll know more in a few days.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Do not understand why are you against such a solution.
> The half-way is IMHO always better then no-way :)
Half-assed means that users rely on the design paradigm, only to discover
later that it isn't portable.
Part of the flaw was that this should have been noticed by the person who
implemented the API on the Win32 platform with an obervation that it wasn't
portable.
Then one of three things happen, we choose not to implement it, we choose
to implement with a #define that warns the user the pattern isn't portable
or available in the current compilation, or we return ENOTIMPL to warn them
at run time it's not available.
You aren't solving the problem of helping users write portable code, which
is the reason for my ongoing objection.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Do not understand why are you against such a solution.
> The half-way is IMHO always better then no-way :)
Half-assed means that users rely on the design paradigm, only to discover
later that it isn't portable.
Part of the flaw was that this should have been noticed by the person who
implemented the API on the Win32 platform with an obervation that it wasn't
portable.
Then one of three things happen, we choose not to implement it, we choose
to implement with a #define that warns the user the pattern isn't portable
or available in the current compilation, or we return ENOTIMPL to warn them
at run time it's not available.
You aren't solving the problem of helping users write portable code, which
is the reason for my ongoing objection.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Anyhow, the entire idea of modifying calling process msvcrt
> tables sounds a little bit 'hacking' to me, and always will.
> Somehow I don't see that as a right way to go.
The Windows PE format is a low-level well defined construct. I don't quite
see what issue you have with that? You aren't replacing what the msvcrt
has constructed, you are adding. IIUC this should even interoperate with
boost or the pthread library, unless I'm missing something important.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Anyhow, the entire idea of modifying calling process msvcrt
> tables sounds a little bit 'hacking' to me, and always will.
> Somehow I don't see that as a right way to go.
The Windows PE format is a low-level well defined construct. I don't quite
see what issue you have with that? You aren't replacing what the msvcrt
has constructed, you are adding. IIUC this should even interoperate with
boost or the pthread library, unless I'm missing something important.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>
> I'm still -1 on that approach, for the very reason that it doesn't
> produce any consistent results. I'm not arguing that your solution
> isn't a partial answer to the fact that we get -no- results today, but
> I'm arguing that the right solution beats half a solution.
>
Do not understand why are you against such a solution.
The half-way is IMHO always better then no-way :)
Anyhow, the entire idea of modifying calling process msvcrt
tables sounds a little bit 'hacking' to me, and always will.
Somehow I don't see that as a right way to go.
Further more, from a pragmatic point of view.
If we were able to live for so long without that,
why can't we live any more with the something better?
Regards,
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>
> I'm still -1 on that approach, for the very reason that it doesn't
> produce any consistent results. I'm not arguing that your solution
> isn't a partial answer to the fact that we get -no- results today, but
> I'm arguing that the right solution beats half a solution.
>
Do not understand why are you against such a solution.
The half-way is IMHO always better then no-way :)
Anyhow, the entire idea of modifying calling process msvcrt
tables sounds a little bit 'hacking' to me, and always will.
Somehow I don't see that as a right way to go.
Further more, from a pragmatic point of view.
If we were able to live for so long without that,
why can't we live any more with the something better?
Regards,
Mladen.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Are you sure this works in native, or only on x86 emulated
> mode on those processors?
>
> I have tried almost everything, but since link says it
> is a read-only thing on those CPU's I'm stuck.
Brane - can you offer any additional insight here?
Mladen, perhaps modify trunk to follow this schema so that Brane can work
behind and offer the patch that will solve the issue?
> Since all this is a hack, IMHO we can simply exploit the
> feature from DLL apr build, and leave the current
> status for LIB builds like it was before.
> (BTW, my patch does that).
I'm still -1 on that approach, for the very reason that it doesn't
produce any consistent results. I'm not arguing that your solution
isn't a partial answer to the fact that we get -no- results today, but
I'm arguing that the right solution beats half a solution.
Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h
misc/win32/start.c threadproc/win32/threadpriv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mladen Turk wrote:
>
> Are you sure this works in native, or only on x86 emulated
> mode on those processors?
>
> I have tried almost everything, but since link says it
> is a read-only thing on those CPU's I'm stuck.
Brane - can you offer any additional insight here?
Mladen, perhaps modify trunk to follow this schema so that Brane can work
behind and offer the patch that will solve the issue?
> Since all this is a hack, IMHO we can simply exploit the
> feature from DLL apr build, and leave the current
> status for LIB builds like it was before.
> (BTW, my patch does that).
I'm still -1 on that approach, for the very reason that it doesn't
produce any consistent results. I'm not arguing that your solution
isn't a partial answer to the fact that we get -no- results today, but
I'm arguing that the right solution beats half a solution.