Dear list readers, beginners,i have made a small tutorial on how to get MinGW MSYS / MinGW-w64up and running, as well as how to compile Qt 4.8.1 as dynamic andstatic, how to configure Qt Creator to use the MinGW-w64 toolchain and how to compile Qt IFW with MinGW-w64.- First of all, and as i don't k
I fixed the problem. It was caused by out of order link lib statements.
Link order is important sometimes.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landsc
Hi Ruben :)
> Did you use the fancy gerrit stuff? Otherwise you will be completely ignored,
> unfortunately.
As a matter of fact i didnt. i wasn't even aware that this was required,
and i will try to do that right now.
> Qt people aren't very receptive of MinGW(-w64) related stuff, as you could
> Use MSVCR100, you don't need to deal with manifests there, MS finally
> dropped it.
Phew! Very good news. i will keep that in mind for my own projects,
as i would like to avoid making Qt IFW change to their project files.
Thanks JonY! Yet another good piece information :)
Pierre.
--
On 5/16/2012 02:54, Kai Tietz wrote:
> 2012/5/15 MARTIN Pierre :
>> Kai,
>>
>>> Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It
>>> provides its own msvcr??.dll version by of course contains this
>>> symbol.
>> Understood.
>>
>>> You can build your application with gcc also f
2012/5/15 MARTIN Pierre
> Dear MinGW-w64 list, and readers that might have ended here out of
> curiosity,
>
> Patching of Qt IFW so it compiles with MinGW-w64 against a statically
> built version of Qt
> is now complete. It requires very very small amount of changes, and i have
> submitted
> them
Dear MinGW-w64 list, and readers that might have ended here out of curiosity,
Patching of Qt IFW so it compiles with MinGW-w64 against a statically built
version of Qt
is now complete. It requires very very small amount of changes, and i have
submitted
them to the Qt IFW maintainers so they can
>> I apologize for my two cents, but tell me please, what 'Qt IFW' the project
>> is?
> It is a very interesting project (Qt IFW stands for Installer Framweork). i'm
> able
> to build installer that can check for updates online against XML files that
> you
> craft with your different component i
> I apologize for my two cents, but tell me please, what 'Qt IFW' the project
> is?
It is a very interesting project (Qt IFW stands for Installer Framweork). i'm
able
to build installer that can check for updates online against XML files that you
craft with your different component information.
2012/5/16 MARTIN Pierre:
> ... binaries generated by the Qt IFW project
I apologize for my two cents, but tell me please, what 'Qt IFW' the project is?
Thanks!
--
Regards,
niXman
___
my MinGW builds: http://sourceforge.net/projects/mingwbuilds/
---
Dear Kai, Ozkan, and those reading regarding this msvcrt problem,
As i was investigating more and more about the implications of
tweaking the specs of GCC and then having to embed a manifest
into the binaries generated by the Qt IFW project, i finally choosed
to count the functions that were not p
2012/5/15 MARTIN Pierre :
> Dear list readers,
>
> Related to the msvcrXX.dll problem i have, i'm trying to understand
> how to tell my toolchan that i'll be willing to use msvcr80.
> So i found this page: http://www.mingw.org/wiki/SpecsFileHOWTO
> wich is talking about modifying the specs of gcc.
2012/5/15 MARTIN Pierre :
> Kai,
>
>> Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It
>> provides its own msvcr??.dll version by of course contains this
>> symbol.
> Understood.
>
>> You can build your application with gcc also for different
>> runtime-library, but you have t
Dear list readers,
Related to the msvcrXX.dll problem i have, i'm trying to understand
how to tell my toolchan that i'll be willing to use msvcr80.
So i found this page: http://www.mingw.org/wiki/SpecsFileHOWTO
wich is talking about modifying the specs of gcc.
However, something is unclear and re
Kai,
> Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It
> provides its own msvcr??.dll version by of course contains this
> symbol.
Understood.
> You can build your application with gcc also for different
> runtime-library, but you have to specify it manually. Also be aware
2012/5/15 MARTIN Pierre :
> Hi Kai,
>
>> This symbol isn't present for older msvcrt.dll versions. Means this
>> issue can happen on OS versions of Windows, where the msvcrt.dll
>> doesn't provide this export. What OS you were actual here using?
> Hm. This would make sense but note the following:
On 5/15/12, MARTIN Pierre wrote:
> Hi Kai,
>
>> This symbol isn't present for older msvcrt.dll versions. Means this
>> issue can happen on OS versions of Windows, where the msvcrt.dll
>> doesn't provide this export. What OS you were actual here using?
> Hm. This would make sense but note the fol
Hi Kai,
> This symbol isn't present for older msvcrt.dll versions. Means this
> issue can happen on OS versions of Windows, where the msvcrt.dll
> doesn't provide this export. What OS you were actual here using?
Hm. This would make sense but note the following: when compiling
the same program wi
2012/5/15 MARTIN Pierre :
> Hello list readers,
>
> i have successfully managed to compile Qt IFW with MinGW-w64.
> i will submit the set of patches to the maintainers, as they requested.
> However, once compiled, i have an error when starting any of the
> generated binary:
> "The procedure entry p
Hi Teemu,
> I personally use Ralph Engels' environment which has pretty much
> everything I need, except Qt. It is a combination of MSYS and MinGW-w64.
> I think you can safely replace the GCC Ralph uses with Ruben's GCC.
> http://sourceforge.net/projects/cbadvanced/
i wasn't aware of this thig.
Hello list readers,
i have successfully managed to compile Qt IFW with MinGW-w64.
i will submit the set of patches to the maintainers, as they requested.
However, once compiled, i have an error when starting any of the
generated binary:
"The procedure entry point _wsopen_s could not be located in
On 15.5.2012 16:02, MARTIN Pierre wrote:
> i'm a bit confused, and would like to hear from you all: what do
> you usually do, as a rule of thumb, when requiring another
> package? Is there an un-official (Off-list if needed) where i can get
> something similar to MinGW-Get, but for the MinGW-w64 v
On Tue, May 15, 2012 at 11:39 AM, Kai Tietz wrote:
> Hello Anthony,
>
> those symbols are present in our libmingwex.a library. So I assume
> that there might be a link-order issue.
Or perhaps a link command issue? If you use GCC or G++ to link then
these frontends should add the most common lib
Hello Anthony,
those symbols are present in our libmingwex.a library. So I assume
that there might be a link-order issue.
Regards,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways tod
Hi Ozkan,
> What is your command line?
Thanks to your question, i just checked the command line,
and i figured that -lmpr wasn't here...
#pragma comment(lib, "mpr.lib") was instead in the C++
code itself...
Now, i'm reading that those #pragma comment lib are more
MSVC oriented. So i added -lmpr
On 5/15/12, MARTIN Pierre wrote:
> Dear list,
>
> i'm trying to make a set of patches for the Qt Installer Framework.
> i have corrected most of the errors i have found (But will request
> a few advices later about the win32 API offering functionA and
> functionW based on the charset). Right now,
Dear list,
i'm trying to make a set of patches for the Qt Installer Framework.
i have corrected most of the errors i have found (But will request
a few advices later about the win32 API offering functionA and
functionW based on the charset). Right now, the only thing i'm
working on is linking.
i
Dear Earnie,
> What file type are you trying to archive/unarchive? MSYS provides
> msys-zip and msys-unzip for .zip files. Also there is a msys-xz which
> will pack/unpack .lzma and .xz.
> So do you really need 7zip and if so why?
i really need 7z. The reason is that i'm using Qt IFW that uses t
On Mon, May 14, 2012 at 6:56 PM, Antony Riakiotakis wrote:
> Ah, looks like the reason for the strange behaviour was my using
> release with debug info build type for cmake. Optimizations play funky
> with the debugger it seems. Now all is in order...phew.
>
If you're debugging code you should st
On Tue, May 15, 2012 at 9:02 AM, MARTIN Pierre wrote:
> i have a quick question about this MSYS environment. i primarily
> use it because all my scripts are initially made on an unix system,
> and are also being ran on my Debian machine. i didn't want to go
> through the hassle of making windows b
> Hi Jony,
Ooops. Sorry for the mix-up Jon. i just figured you
weren't JonY :)
Pierre.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed a
Hi Jony,
> As part of another project, I aggregate the mingw.org MSYS packages with
> mingw-w64 builds...we call it the oh so clever...wait for it...DevKit.
> It's got other goodies and things that make Ruby on Windows users happy, but
> it's also a standalone development toolchain.
> Currently
> > Then what is the point of the MinGW-w64 version of the MSYS
> > package? Only changes to /etc or something more complex?
> > This package originated from before mingw-get. I like the unzip+use
> > philosophy for development tools, as I move stuff around a lot. So I
> > manually downloaded all
> Don't know, I use the latest MSYS stuff from their downloads site.
Ok!
> So let's say i just put the original mingw-get binary in the
> MinGW-w64 version, it would then work with other programs
> installed via mingw-get?
> It should work, but again: if you like mingw-get, just use that.
This i
2012/5/15 MARTIN Pierre
> > Do not try to build MSYS programs yourself. It's very nontrivial (if not
> impossible except for those who know exactly how it works) and a waste of
> time.
> Ah! That was a bad idea from me to try on the first place then.
>
> > If MSYS does not provide something you n
> Do not try to build MSYS programs yourself. It's very nontrivial (if not
> impossible except for those who know exactly how it works) and a waste of
> time.
Ah! That was a bad idea from me to try on the first place then.
> If MSYS does not provide something you need, either go for Cygwin or
2012/5/15 MARTIN Pierre
> Dear list readers,
>
> As you all might know, i'm using Ruben's version of the toolchain. It's
> working very well for my needs, and on the side i'm also using
> MinGW-w64's version of MSYS (The tarball found on the sourceforge
> page).
>
> i have a quick question about
Hello Ruben!
On Tue, May 15, 2012 at 8:37 AM, Ruben Van Boxem
wrote:
> 2012/5/15 K. Frank
>
>> Hi Joshua!
>>
>> On Tue, May 15, 2012 at 3:54 AM, Joshua Boyce
>> wrote:
>> > On Tue, May 15, 2012 at 1:08 AM, K. Frank wrote:
>> >>
>> >> By the way, a quick semi-related question: To use native wi
Dear list readers,
As you all might know, i'm using Ruben's version of the toolchain. It's
working very well for my needs, and on the side i'm also using
MinGW-w64's version of MSYS (The tarball found on the sourceforge
page).
i have a quick question about this MSYS environment. i primarily
use i
2012/5/15 K. Frank
> Hi Joshua!
>
> On Tue, May 15, 2012 at 3:54 AM, Joshua Boyce
> wrote:
> > On Tue, May 15, 2012 at 1:08 AM, K. Frank wrote:
> >>
> >> By the way, a quick semi-related question: To use native windows
> >> Sleep I am including windows.h. It's not a big deal, but it does
> >>
Hi Joshua!
On Tue, May 15, 2012 at 3:54 AM, Joshua Boyce
wrote:
> On Tue, May 15, 2012 at 1:08 AM, K. Frank wrote:
>>
>> By the way, a quick semi-related question: To use native windows
>> Sleep I am including windows.h. It's not a big deal, but it does
>> increase the compile time of simple t
In C, I'm trying to portably implement gmtime_r (I'm aware of the gmtime_r
macro and comments in time.h) using gmtime_s and this snippet appears to work
fine. What's a cleaner or more robust solution?
#include
#include
#include
#if defined(__MINGW64_VERSION_MAJOR)
/* XXX why isn't this in s
2012/5/15 MARTIN Pierre
> Ruben,
>
> I applied a patch to make GCC's configure detect a newer CLooG version
> (0.17), and modified two typedefs which are required for a newer ppl
> version. The last change is present upstream already.
>
> Thank you for explaining. Is there a changelog of your wor
Ruben,
> I applied a patch to make GCC's configure detect a newer CLooG version
> (0.17), and modified two typedefs which are required for a newer ppl version.
> The last change is present upstream already.
>
Thank you for explaining. Is there a changelog of your work, or
a git with a set of pat
On Tue, May 15, 2012 at 1:08 AM, K. Frank wrote:
>
> By the way, a quick semi-related question: To use native windows
> Sleep I am including windows.h. It's not a big deal, but it does
> increase the compile time of simple test programs noticeably.
> (Not really a lot, though.) Would anyone kn
Op 14 mei 2012 22:27 schreef "MARTIN Pierre" het
volgende:
>
> Dear Ruben,
>
> > Just for reference: no patching done on my side. The only things I
would patch (for release build things) are build related things, which do
not affect the workings of the program at all.
> What could typically be "bu
46 matches
Mail list logo
