ok, i just want to confirm.
I patched the cygwinccompiler.py file to /return ['msvcr90'] /(line
77) when /get_msvcr()/ is called.
So if a build the Sip.pyd with mingw, and inspect the result in
DendencyWalker I should see that Sip.pyd depended on MSVCR90 and
not MSVCRTL ?
Because after the
One other thing , i configure Sip with
/python configure.py DEFINES+=MS_WIN64 -p win32-g++/
Does it change something? For me it works without MS_WIN64.
(I am glad I compiled everything I needed, only occasionally rebooting
to windows for a build; so I don't feel like experimenting with such
I went through the build-all.sh script in detail, to be found in the
attchement of
http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/6511
I also looked at the python patches, i had to patch the files manually.
In the build-all.sh script a pydistutils.cfg file is created.
How is
Thank You for all the information, it really helped a lot.
But still things don't work correctly.
I had a good look at your shell script build-all.sh
I installed Python 2.7.3 64bit manually and applied the patch for python
I Compiled Sip 4.14.3 and install it.
I Compiled PyQt-win-gpl-4.9.6 and
On 13/03/13 07:17, Theuns Heydenrych wrote:
Hi, I know this is not a Python mailing list, but i am desperate.
Someone in StackOverflow
I am compiling Sip and PyQt from source using Mingw64 and Python 2.7.3
64bit.
Python binaries is installed via downloaded installer, and is build
with
Let me run it in debugger for you, okay? (gcc 4.7.2 under Linux):
#0 0x77538425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7753bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x77b37e2d in __gnu_cxx::__verbose_terminate_handler() ()
from
Fwd to the list:
Original Message
Subject:Re: [Mingw-cross-env-list] Boost.Python extension (cmake)
Date: Mon, 11 Feb 2013 15:32:10 +0100
From: h...@robin-jadoul.ciki.me
To: Václav Šmilauer e...@doxos.eu
I actually managed to use 7zip to extract python from
Let me run it in debugger for you, okay? (gcc 4.7.2 under Linux):
#0 0x77538425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7753bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x77b37e2d in __gnu_cxx::__verbose_terminate_handler() ()
from
just for your Projects successfully using MinGW-w64 links
TYCHO (http://www.tycho-cfd.at) uses MinGW and likes it!
Me too! The Woo DEM simulator uses Mingw64: http://www.woodem.eu .
Cheers, Vaclav
--
Master HTML5,
I am in the process of uploading a GCC 4.7 build with posix threading
(this means all the C++11 multithreading functionality in thread and
mutex should work).
This build is experimental, mostly because it's ABI incompatible
with my other builds. Every C++ and some C applications will
recently I am trying to cross compile some base GNU libraries for both
32bit and 64bit Windows host. The build system is Debian 6.0.6. I am
using Ruben's personal build
(xxx-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar).
When building glib with the x86_64 target, I get the following
I am afraid that if I for example take the long time to install MXE, I
would end up with exactly the same problem.
MXE installation is next to trivial. The version of glib they have now
is 2.28.2, though (their patch is
https://github.com/mxe/mxe/blob/master/src/glib-1-fixes.patch).
Good
Hi, when I run the gdb (python enabled) under drmemory, like:
drmemory gdb.exe
I see a lot of error reports regarding about memory error related to python
dll, like below:
(ERROR 3)
Since I assume drmemory is something akin to valgrind, I can generally
comment on its combination with
Hi,
I understand gendef generates symbols from non-mingw DLLs so that linker
knows which symbols are defined.
What is thereason to have gendef, instead of making the linker
understand the PE(+) formats so that it can read exported symbols from
the DLL directly, at link time? Technical
This is a small question with much more impact as you might expect.
Old style is to put Runtime-DLL files into bin/ directory. This had
some advantages as long as you just have one target to support, but in
general isn't the best solution IMHO.
More modern gcc installs its runtime-DLL files
I will try to do that, thanks for advice. It is a bit tedious, and many
templates are declared in headers, so I am not sure how far I will get
with that.
For the record, I compared -Os and -O2 options in gcc - they differ only
in -fintline-functions (enabled with -Os, disabled with -O2) and
Hi there,
I would like to ask what the best/recommended practice for installing
shared libraries under Windows/mingw is. Qt4 for instance installs DLLs
to both $PREFIX/bin and $PREFIX/lib. I prefer to install to $PREFIX/lib
and add it to $PATH (in addition to $PREFIX/bin), but I wonder if
I am using your toolchains (thanks for them :-) ), the 64bit flavor. Are
those messages indicative of files being too big, or is it rather large
number of sections (lots of templates?) the culprit?
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/as.exe:
Common practice is to put the DLL in the $PREFIX/bin directory and to
put the import libraries in $PREFIX/lib. Since it is common practice
doing otherwise might upset your users.
What do you mean by import libraries here? DLLs which get
LoadLibraryEx'd at runtime and which are not needed for
Hello,
I got recently hit by compilation error due to dlgs.h (included from
windows.h) #defining several macros with common names - in my case rad1,
rad2 (for radius 1, radius 2). Are those part of Windows API or could
they be renamed to something less prone to conflict with user code, or
I got recently hit by compilation error due to dlgs.h (included from
windows.h) #defining several macros with common names - in my case rad1,
rad2 (for radius 1, radius 2). Are those part of Windows API or could
they be renamed to something less prone to conflict with user code, or
perhaps
I am currently compiling several 3rd-party libraries which I need for my
code. Among those are glib, VTK, Qt and perhaps several others. I have
the (32bit) MSYS installed, which provides standard directories like
/usr/lib, /usr/include, ...
These should not be present, if they are, it is
For reliability, cross compiling on Linux is always a good idea.
I tried that (with http://mxe.cc), but cross-compiling python seems to
be quite tricky (it will never be supported for 2.7, and is still in
works for 3.3+). So I am unwillingly at windows now, hoping that I will
be able to go
Just for the heck of it, I changed
Python27/lib/distutils/cygwincompiler.py to return msvcrt instead of
msvcr90. It works.
My question is: do we really need to link our modules to msvcr*, if
python.dll (which we link already when building modules) links to msvcrt
itself? I assume there is
I'm hoping my load fail (and the OP's) turns out to be the issue of
modules linking against two different CRT versions. PeStudio tells me
my msvcrt.dll linked .pyd's try to use _errno, __dllonexit, fflush,
free, malloc, and strcmp from msvcr90.dll.
Just for the heck of it, I changed
I'm hoping my load fail (and the OP's) turns out to be the issue of
modules linking against two different CRT versions. PeStudio tells me
my msvcrt.dll linked .pyd's try to use _errno, __dllonexit, fflush,
free, malloc, and strcmp from msvcr90.dll.
Just for the heck of it, I changed
Hi, Vaclav!
Can you try to build python module with this toolchain
https://www.dropbox.com/s/hwst18lywbw74vv/x64-4.7.2-release-posix-sjlj-rev1.7z?
There are Python-2.7.3 in subdirectory opt compiled with this toolchain.
Hi Alex,
thanks for your suggestion, I would like to first try with
2a) [!!!] run gendef and dlltool on python27.dll
(http://stackoverflow.com/q/11182765/761090) to be able to -lpython27.
How is that suspicious?
Having no experience here, I thought it was some hack. You seem to
suggest this is the standard way. Good :-)
3a) Copy msvcr90.dll
3c) Move 32bit libs out of the way
(http://gcc.gnu.org/ml/gcc-help/2012-07/msg00060.html suggests to use
-static-libstdc++, but it is not recognized by gcc 4.7); I don't compile
32bit programs, so not having 32bit versions is fine for me:
cd /c/MinGW64/bin
mv libstdc++-6.dll
Hi everybody,
I was hitting the File too large error triggered by as.exe trying to
write some files. I somehow managed to work around it by splitting
compilation in smaller parts, by compiling without -g and/or with -Os.
Why is it that a native 64bit compiler is hitting this 32bit limit? Is
I settled for the fix of using mingw.org gcc 4.6.2 32bit but don't understand
why it works since the 4.6.2 .pyd's still have deps on msvcr90.dll and msvcrt.dll...need
to try again with a custom spec to force everything to msvcr90.dll and try with
when compiled as C++, gives the error of no strerror_s declared, but
when compiled as C, works fine.
You could compare preprocessed source with both compilers:
echo #includestring.h | gcc -E -
echo #includestring.h | g++ -E -
Cheers, Vaclav
32 matches
Mail list logo
