Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building on Windows with a runtime other than the one Python uses makes Enso not work #11

Open
GoogleCodeExporter opened this issue Jan 28, 2016 · 2 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Build on Windows, linking to a dynamically loaded runtime other than the
one Python uses
2. Run Enso
3. Fail to start - due to different dynamically loaded runtimes in the same
process (fails with cryptic error message)

What is the expected output? What do you see instead?
At the moment, stuff is built with the dynamically loaded multi-threaded
runtime (compiler switch /MD). It should be built with a statically linked
runtime (compiler switch /MT), so that Enso can be run no matter how Python
was built.

What version of the product are you using? On what operating system?
Windows.

Original issue reported on code.google.com by [email protected] on 22 Mar 2008 at 6:19

Attachments:

@GoogleCodeExporter
Copy link
Author

IIRC, the potential problem with this approach is that it means that two 
separate
instances of the C runtime exist in the same process space.  This means that 
certain
things, like file pointers, can't be exchanged from one CRT instance to 
another--or
rather, they *can* be exchanged, but it'll cause a segfault.  I believe that we
encountered this fairly early on in Enso development, but I'm not 100% sure.  I 
was
also under the impression that the reason C extension modules like pywin32 
require
you to download a different installer depending on your version of Python was 
due to
this issue.

Are there any major Python C extension modules that statically include the CRT 
like this?

Original comment by [email protected] on 24 Mar 2008 at 4:20

@GoogleCodeExporter
Copy link
Author

Yes, I realise that was a major hack - but it was a required hack to get it 
working
quick and easy. Even if it was a Bad Thing (tm).

I just recompiled without linking to CRT (no /MD or /MT - used /LD instead), and
everything seems to be working fine.

Needs to be really tested - but maybe we can skip out CRT altogether?

Original comment by [email protected] on 25 Mar 2008 at 5:28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant