Which build-style of the wxWidgets does wxPhoenix use?
I need to build wxWidgets manually with TDM-GCC and hope the
build-script of Phoenix can handle this.
Which build-style of the wxWidgets does wxPhoenix use?
I need to build wxWidgets manually with TDM-GCC and hope the
build-script of Phoenix can handle this.
wxPython is a Python extension, so even if you can build wxWidgets using a different compiler, it won't matter if that compiler doesn't produce a binary that works with the Python you have installed. wxPython's build scripts use MSVC because that is what Python itself uses. See:
https://docs.python.org/2/extending/windows.html
Particularly important is the last part of the second paragraph. So building with something other than MSVC is not really a practical option for the wxPython project, because it needs to produce binaries that work with stock Python, and that means something built using MSVC.
If you want to build wxPython with something other than MSVC, you need to start by building your Python that way, and be aware that any extension you build will almost certainly not work with stock Python. I wish you luck, but avoiding filling out that form is likely to result in you spending hours or quite possibly even dozens of hours finding some way of getting everything building with an alternate compiler chain.
Regards,
Kevin
···
On May 7, 2015, at 11:44 AM, c.buhtz@posteo.jp wrote:
--
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxPython-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> I need to build wxWidgets manually with TDM-GCC and hope the
> build-script of Phoenix can handle this.wxPython is a Python extension, so even if you can build wxWidgets using a
different compiler, it won't matter if that compiler doesn't produce a
binary that works with the Python you have installed. wxPython's build
scripts use MSVC because that is what Python itself uses. See:4. Building C and C++ Extensions on Windows — Python 2.7.18 documentation
For what it's worth, some third party compilers can build extensions that
are compatible with the MSVC-built python (mingw, for instance), and I'm
pretty sure some folks are using TDM-GCC as well.
I"d checkout the numpy/scipy communities, there's a lot of work going on
there with that.
Here is one example:
http://deeplearning.net/software/theano/install_windows.html
But I imagine you've got your work cut out for you in any case.
-Chris
···
On Thu, May 7, 2015 at 12:03 PM, Kevin Ollivier <kevino@theolliviers.com> wrote:
On May 7, 2015, at 11:44 AM, c.buhtz@posteo.jp wrote:
Particularly important is the last part of the second paragraph. So
building with something other than MSVC is not really a practical option
for the wxPython project, because it needs to produce binaries that work
with stock Python, and that means something built using MSVC.If you want to build wxPython with something other than MSVC, you need to
start by building your Python that way, and be aware that any extension you
build will almost certainly not work with stock Python. I wish you luck,
but avoiding filling out that form is likely to result in you spending
hours or quite possibly even dozens of hours finding some way of getting
everything building with an alternate compiler chain.Regards,
Kevin
> --
> You received this message because you are subscribed to the Google
Groups "wxPython-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
an email to wxPython-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.--
You received this message because you are subscribed to the Google Groups
"wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxPython-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Hi!
The reason for using the same tools as Python is not directly the compiler, it's the C library (Microsoft Visual C Runtime Library, CRT). The CRT version used depends on the VS version and whether it's a release or debug build.[1]
The consensus[2] seems to be to strive to have all code linked into executable (the exe itself + all DLLs) use the same CRT version. Mixing versions may seem to work, but is often subtly broken if one CRT ever sees objects created by another CRT (e.g. stdin/stderr/stdout FILE* objects, malloc_CRT1() -> realloc_CRT2(), all of C++).
As I understand it, MinGW uses the CRT from Visual Studio 6, so it doesn't resolve this problem. Cygwin uses it's own C runtime library (CYGWIN1.DLL), but that's also incompatible with VS compiled code.
I don't know about TDM-GCC.
In the end, it's possible to use any compiler desired, it's just a good idea to build _all_ code, including used DLLs, with that compiler to get sane library dependencies.[3]
Cheers,
Chris
[1]: True for all current VS versions, but versions >= VS2015 will
use a common CRT for multiple VS versions, thankfully:
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx
[2]: Learn why - Mixing Multiple Visual Studio Versions is Evil | SiOM Systems
The dreaded "application configuration is incorrect" error - virtualdub.org
Fighting the MSVCRT.DLL hellSyndicate Of Ideas
[3] Check using depends.exe from http://www.dependencywalker.com
···
On 08.05.2015 02:21, Chris Barker wrote:
For what it's worth, some third party compilers can build extensions
that are compatible with the MSVC-built python (mingw, for instance),
and I'm pretty sure some folks are using TDM-GCC as well.