Re: DEBUG binaries for win32/win64

2019-02-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/25/19 09:42, Mark Thomas wrote:
> On 25/02/2019 14:17, Christopher Schultz wrote:
>> All,
>> 
>> At the risk of making the build for Windows even more onerous,
>> would it be possible to distribute DEBUG builds along with the
>> standard ones?
>> 
>> The native stack trace in this bug report[1] for example is 
>> non-existent and useless because it just says:
>> 
>> # Problematic frame: # C  [tcnative-1.dll+0x60895]
>> 
>> If I had a Windows development environment and that same version
>> from the svn branch and my compiler settings were exactly what
>> was used by the Release Manager for that particular version, I
>> might be able to resolve tcnative-1.dll+0x60895 to the right
>> function and, nf I'm lucky, the right line of code.
>> 
>> But the compiler can build all that into the binary, so why
>> bother fiddling with all that nonsense? We should be able to tell
>> the bug-reporter "please replace the regular build with the DEBUG
>> one and try again to get better data" and, likely, we'll get
>> better data.
>> 
>> WDYT?
> 
> It probably means debug builds for OpenSSL and APR as well.
> 
> Speaking as the current RM, if someone updates [2] I have no
> objection to turning the handle. If the expectation is that I
> figure out what changes are required then it will happen (I think
> it is a good idea) but it is going to take longer.

I think (*think*!) that building a debug version of a binary with
msvc++ just requires adding /DEBUG to the command-line, so it should
be fairly straightforward. Building tcnative with /DEBUG should be
easy even if we don't bundle a DEBUG version of APR and/or OpenSSL.
Can we try that to begin with?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlx0BOQACgkQHPApP6U8
pFgQmQ/+LaZX5vRFlrKEGfkCdcy14atOBL0mxwQT7g42wkiCqiyc+RwEkXcoVj0D
tiSKGm/7cha4Vp20Ni+jVMsHff1oaOhY5i/5KJTWaPwH7FCpMcfkH7dPyOJVMqc3
fofyWxgr/41kRI2HPDgkKrF+e87xrrOF+Z2JGEnLnoSWAGxv02Bd6oevE0VYEpH1
6tCCRVIUzCdsnzouMzn2kIUhtYvyb3v1uYTqWvxIlnRgSB2OtIzweM07PNyOhse9
GiVn0EahK3wHy9Wm7V07g7TI1JckZZaxIpmmAEzxfZFCw2nm1rhnCHc2ldPgyWMS
/2bbN+oEqwJiIZRVM3r2NhZn35UXcFS9s/tkM/69WFMho81oFYylk/eFfhDqtkpU
UBXdQ2svsTyIfNJNFzIDSCjOLttmfKjC+8NIeiTK3eEoBTBW5q/PAcPhOqYaEwje
ZtSAeqwrnmNwXU1sZ6EiiyafK0uFmWDgREaF+M8QjGBsacv21DdqqKlQIEWDMiFk
Y0QaVKGfAycYLYkPHdvvGkAOVsvBuY5SIFrJja00MBXfqHSgMjSPPo3xBCEGyISa
OAVVad9AMVRMPLHgvf/5kuDm71YpgYBQxWZZQP6eU7r9e9qQmYgvvRdl6LAGSxZi
3cd513CXHEBqPrrxhQKG1p8oE76BVsThF9K6TLlktubr8jqGLZI=
=ak/E
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: DEBUG binaries for win32/win64

2019-02-25 Thread Mark Thomas
On 25/02/2019 14:17, Christopher Schultz wrote:
> All,
> 
> At the risk of making the build for Windows even more onerous, would
> it be possible to distribute DEBUG builds along with the standard ones?
> 
> The native stack trace in this bug report[1] for example is
> non-existent and useless because it just says:
> 
> # Problematic frame:
> # C  [tcnative-1.dll+0x60895]
> 
> If I had a Windows development environment and that same version from
> the svn branch and my compiler settings were exactly what was used by
> the Release Manager for that particular version, I might be able to
> resolve tcnative-1.dll+0x60895 to the right function and, nf I'm
> lucky, the right line of code.
> 
> But the compiler can build all that into the binary, so why bother
> fiddling with all that nonsense? We should be able to tell the
> bug-reporter "please replace the regular build with the DEBUG one and
> try again to get better data" and, likely, we'll get better data.
> 
> WDYT?

It probably means debug builds for OpenSSL and APR as well.

Speaking as the current RM, if someone updates [2] I have no objection
to turning the handle. If the expectation is that I figure out what
changes are required then it will happen (I think it is a good idea) but
it is going to take longer.

Mark


[2]
https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows


> 
> Thanks,
> -chris
> 
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63199#c0
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



DEBUG binaries for win32/win64

2019-02-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

At the risk of making the build for Windows even more onerous, would
it be possible to distribute DEBUG builds along with the standard ones?

The native stack trace in this bug report[1] for example is
non-existent and useless because it just says:

# Problematic frame:
# C  [tcnative-1.dll+0x60895]

If I had a Windows development environment and that same version from
the svn branch and my compiler settings were exactly what was used by
the Release Manager for that particular version, I might be able to
resolve tcnative-1.dll+0x60895 to the right function and, nf I'm
lucky, the right line of code.

But the compiler can build all that into the binary, so why bother
fiddling with all that nonsense? We should be able to tell the
bug-reporter "please replace the regular build with the DEBUG one and
try again to get better data" and, likely, we'll get better data.

WDYT?

Thanks,
- -chris

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63199#c0
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxz+Q4ACgkQHPApP6U8
pFhuuBAAuTVcPtYBP7IsXhcIOdvOnL4mitk4WvxrkDjdzkP2/RwWE0xckBMqNKZl
bzCKHCWO/1VjG33623aCWLeklk9/HXhErTjULvXPwmoplgUJTBmIrWC9lxZ98nD0
sZlANeJG9nCYvNxQWX09qHGYQPfLFW3dAj0sp860diEpKfrfmiHU6V0XF+egWoJF
Lemx7nD5a23EpoKVPHdsgTFImrKa/APw/4g8L3yDVGmyzEfUzfF959iKztRsYt2c
+zMG/iX7ybvDxfQn6RP9Rku2GAOSBKkuR1UCz3L7Aq5Dc9ZmkLnyPzc0jdzv/sqn
A6/aVWXfajIIRrH2niKASwXUtxU6WTgJNi9QDqw+/cqOdj3RlAzbyIxTn5zYwLew
uYLzmubaTd84e8g2L57KCiukjiiz4aYRX8eeWTcHSiJisqVZHNavpQMTqCBZLBrC
iR3XsL5gRBBjkFlUSuBEQ+mXq7WQUhMWiwTH3U3VtGAVrOSMX5AUC/6jm9Z+TQ+K
c/Brz7tlcSLXnLOTsO7ZhgVagl9HVtw07wuf1LlvDXhAVQq25XEatEv+25M8+zhH
gms7hKNNYpF6h+0DpddPWfvC9+cGQ5jrMcCHBAz7YwJvYY8J9SO5xDkB4cXdXCqo
HnGl2TsRKb824s2hxbTuIhuGgxAIUpco3C/MXNmq2/1/NVEiJp0=
=KSaq
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org