PCBuild9 _ssl.vcproj improperly launches build

[JosephArmbruster]

BPO	1488
Nosy	@tiran
Files	sslbuild.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tiran'
closed_at = <Date 2007-11-23.14:05:20.155>
created_at = <Date 2007-11-22.18:41:50.025>
labels = ['build', 'OS-windows']
title = 'PCBuild9 _ssl.vcproj improperly launches build'
updated_at = <Date 2008-01-06.22:29:44.894>
user = 'https://bugs.python.org/JosephArmbruster'

bugs.python.org fields:

activity = <Date 2008-01-06.22:29:44.894>
actor = 'admin'
assignee = 'christian.heimes'
closed = True
closed_date = <Date 2007-11-23.14:05:20.155>
closer = 'christian.heimes'
components = ['Windows']
creation = <Date 2007-11-22.18:41:50.025>
creator = 'JosephArmbruster'
dependencies = []
files = ['8795']
hgrepos = []
issue_num = 1488
keywords = ['patch']
message_count = 6.0
messages = ['57763', '57764', '57770', '57785', '57786', '57790']
nosy_count = 2.0
nosy_names = ['christian.heimes', 'JosephArmbruster']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue1488'
versions = ['Python 2.6', 'Python 3.0']

[JosephArmbruster]

When you attempt to build the _ssl project in release or debug you can
possibly encounter errors in the following scenarios:

1. having spaces in the build path

2. if you launch the build in debug, it attempts to run build_ssl.py
   with the python.exe found in the path rather than that just built named
   python_d.exe. I believe the solution was designed to run build_ssl.py
   with the binary that was built in the configuration. If this is
   correct, then this patch applies.

3. some of the dependency paths did not appear to point to the correct
   place. Please verify.

See attached patch

[tiran]

Thanks, I'll check it later.

[tiran]

I've fixed (1) and (2) in r59130. I don't understand what you mean with (3).

[JosephArmbruster]

Looks like the libpaths were pointing to out32 instead of out32.dll.
Although that may have been due to my switch from nt.mak to ntdll.mak.

[tiran]

out32 is the correct directory. The windows version of Python is
statically linked against the SSL libs. We don't want to ship yet
another DLL.

[JosephArmbruster]

Whoops. This may have been an error on my part. nt.mak I think bombed
for me except it was probably due to some of my tinkering. My apologies.