On Fri, 2 Nov 2012 15:20:10 -0400
Earnie Boyd wrote:
> On Fri, Nov 2, 2012 at 3:01 PM, Jon wrote:
> >
> > 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
Very well, I'll chew on this over the weekend. Your wisdom is appreciated
indeed. Thank you very much Ruben.
Sent from my iPhone
On Nov 2, 2012, at 15:55, Ruben Van Boxem wrote:
> 2012/11/2 Yves Perron
>> Greetings everyone,
>>
>> Its been a wild ride for me in the cross-platform compilation
2012/11/2 Yves Perron
> Greetings everyone,
>
> Its been a wild ride for me in the cross-platform compilation world. After
> several weeks pulling my hair, I figured it might be a good thing to ask
> for help before I go completely bald.
>
> To resume, I do have a fairly complex C++ "Visual Stud
On Fri, Nov 2, 2012 at 3:01 PM, Jon wrote:
>
> 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
> I am trying to build compiled python modules, which use some compiled
> libraries (boost, in particular). The system is Windows 7 64bit Pro. One
> of them (http://pypi.python.org/pypi/minieigen/0.3-4) works fine,
> another one (source not publicly available yet) does not.
FYI, I had a simil
Greetings everyone,
Its been a wild ride for me in the cross-platform compilation world.
After several weeks pulling my hair, I figured it might be a good thing
to ask for help before I go completely bald.
To resume, I do have a fairly complex C++ "Visual Studio 10 Win64"
project that needs
On Fri, Nov 2, 2012 at 9:42 AM, Ray Donnelly wrote:
>
> I intend my make.exe to (one day) be able to also work from MSYS (by
> hand parsing fstab), cmd.exe and whatever else I can throw it at.
>
Off-topic here but the code already exists, just use it. If you need
to discuss it use the mingw-us...
2012/11/2 Ozkan Sezer
> On Fri, Nov 2, 2012 at 11:54 AM, JonY wrote:
> > On 11/2/2012 16:55, Ozkan Sezer wrote:
> >> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd
> >> wrote:
> >>> Is it properly wrapped in the extern C { } when __cplusplus is
> >>> defined? Is __cplusplus defined correctly?
> >
I wrote a small .bat to do that:
"../src/configure.exe" ^
-fast ^
-shared ^
-static ^
-debug-and-release ^
-opensource ^
-confirm-license ^
-no-dsp ^
-no-vcproj ^
-no-qt3support ^
On 11/2/2012 21:42, Ray Donnelly wrote:
> IMHO, it's MSYS that should've called it's make program msys-make.exe
> and mingw32-make.exe should've been called make.exe, seeing as it's
> the strictly native one here, but I understand that I'm bucking the
> trend. When this make.exe is supplied with Ne
IMHO, it's MSYS that should've called it's make program msys-make.exe
and mingw32-make.exe should've been called make.exe, seeing as it's
the strictly native one here, but I understand that I'm bucking the
trend. When this make.exe is supplied with Necessitas for Windows,
I've renamed it to ma-make
2012/11/2 Ray Donnelly
> Well, I've got my own that I use:
>
> https://mingw-and-ndk.googlecode.com/files/make.exe
>
> It goes through sh.exe a lot less (but also isn't an MSYS program so
> doesn't do the MSYS path transformations), however it may work fine
> for your needs (I've used it to build
On Fri, Nov 2, 2012 at 8:51 AM, Ozkan Sezer wrote:
> On 11/2/12, Earnie Boyd wrote:
>> On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote:
>>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote:
Browsing the SVN data, try including strings.h instead of string.h.
See
http://mingw-w64.sv
Well, I've got my own that I use:
https://mingw-and-ndk.googlecode.com/files/make.exe
It goes through sh.exe a lot less (but also isn't an MSYS program so
doesn't do the MSYS path transformations), however it may work fine
for your needs (I've used it to build Android Qt and MinGW Qt
variants). O
On Fri, Nov 2, 2012 at 9:19 AM, Ray Donnelly wrote:
> Yeah, that's usually down to the way MSYS bash implements fork-like
> behaviour... It's in intermittent thing, I usually wrap my calls to
> make up with a loop to retry a few times! Horrible I know...
>
> The other (better) fix is to use a make.
2012/11/2 Ray Donnelly
> Yeah, that's usually down to the way MSYS bash implements fork-like
> behaviour... It's in intermittent thing, I usually wrap my calls to
> make up with a loop to retry a few times! Horrible I know...
>
> The other (better) fix is to use a make.exe that doesn't use sh.exe
I am using make from. Do you mean to use another make?
On 11/2/2012 2:19 PM, Ray Donnelly wrote:
> Yeah, that's usually down to the way MSYS bash implements fork-like
> behaviour... It's in intermittent thing, I usually wrap my calls to
> make up with a loop to retry a few times! Horrible I know.
Yeah, that's usually down to the way MSYS bash implements fork-like
behaviour... It's in intermittent thing, I usually wrap my calls to
make up with a loop to retry a few times! Horrible I know...
The other (better) fix is to use a make.exe that doesn't use sh.exe
all the time.
On Fri, Nov 2, 201
Ok, thx, I overcome this problem, but now I have another:
g++ -c -Wall -Wextra -Wreturn-type -fno-strict-aliasing -Wcast-align
-Wchar-subscripts -Wformat-security -Wreturn
-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
-Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self
-O2 -fr
On 11/2/12, Earnie Boyd wrote:
> On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote:
>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote:
>>> Browsing the SVN data, try including strings.h instead of string.h.
>>> See
>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-header
On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote:
> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote:
>> Browsing the SVN data, try including strings.h instead of string.h.
>> See
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/crt/string.h?revision=1520&view=mar
On 11/2/2012 18:08, Ozkan Sezer wrote:
> On Fri, Nov 2, 2012 at 11:54 AM, JonY wrote:
>> On 11/2/2012 16:55, Ozkan Sezer wrote:
>>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd
>>> wrote:
Is it properly wrapped in the extern C { } when __cplusplus is
defined? Is __cplusplus defined corr
On Fri, Nov 2, 2012 at 11:54 AM, JonY wrote:
> On 11/2/2012 16:55, Ozkan Sezer wrote:
>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd
>> wrote:
>>> Is it properly wrapped in the extern C { } when __cplusplus is
>>> defined? Is __cplusplus defined correctly?
>>>
>>
>> Yes, sec_api/string_s.h does
On 11/2/2012 16:55, Ozkan Sezer wrote:
> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd
> wrote:
>> Is it properly wrapped in the extern C { } when __cplusplus is
>> defined? Is __cplusplus defined correctly?
>>
>
> Yes, sec_api/string_s.h does that.
>
Tested in g++ 4.8.0 with trunk headers, seem
On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd
wrote:
> Is it properly wrapped in the extern C { } when __cplusplus is
> defined? Is __cplusplus defined correctly?
>
Yes, sec_api/string_s.h does that.
On Thu, Nov 1, 2012 at 7:06 PM, Earnie Boyd
wrote:
> On Thu, Nov 1, 2012 at 11:27 AM, Ruben Van
> -Original Message-
> From: ext CanisMajorWuff [mailto:canismajorw...@gmail.com]
> Sent: Friday, November 02, 2012 6:49 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] incorrect syntax while building QT 4.8.3
>
> Hello!
>>
> I have troubles building QT 4.8.3.
26 matches
Mail list logo
