Dear Baruch,
> Ruben, would you be able to write up a simple tutorial or something,
> explaining how you do your builds so that we can make a few tweaks and build
> our own?
> Or maybe someone else? I seem to remember running into trouble when trying to
> use the bundled compilation instruction
Dear list readers,
>> Yes, this: "-static" when you link the installer executable will pull in
>> static libraries if available, and my toolchains have everything in DLL and
>> static library form.
> As simple as that? i had read that, but i thought it was specific
> to one single user build. A
Dear Ruben, dear Xunxun,
> Yes, this: "-static" when you link the installer executable will pull in
> static libraries if available, and my toolchains have everything in DLL and
> static library form.
As simple as that? i had read that, but i thought it was specific
to one single user build. Ag
Dear list readers,
i have a question relative to the MinGW-w64 runtimes (Correct
me if i'm wrong: libgcc_s_sjlj-1.dll and libstdc++-6.dll).
All my projects are fine with the dynamic version of the runtimes.
But one of my project (In fact an installer) would require a static
version of those DLLs,
> Off-topic:
> Sorry for the OT, but I wanted to point out that MSVC is actually free. The
> higher-end versions of Visual Studio cost money, but the express editions are
> free, as is the standalone Windows SDK, both of which provide a complete
> development environment including MSVC.
Yes Josh
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
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.
--
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.
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
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
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
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
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
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
> 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
> 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
> 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
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
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
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 "build-related things"? Do you mean
the makefiles for instance, ne
> Go ahead and make a bug report, thanks. Dlltool for mingw and mingw-w64
> are really the same, I don't think Ruben does any patching for binutils.
Done, right there:
https://sourceforge.net/tracker/?func=detail&aid=3526550&group_id=202880&atid=983354
Thank you all for your help, right now i know
Dear Kai, JonY, Ozkan and list readers,
As suggested by list users, i have filled a bug report right here:
https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
If you think it's not clear enough, i would like your feedback about
what i could possibly detail about, o
Dear Kai, dear list readers,
> No, gendef seems to add double @ symbol happily. You can file a
> bug about gendef to our bugtracker for this.
i surely will.
> Simply remove double @ at line end. things like ...@12@12 to ...@12.
Done.
> As long as they aren't accessed it should work, but better
Dear Kai, dear list readers,
> See as example the export 'DllMain@12@12'. This is the main-entry of
> DLL and has just the extension @12 and not @12@12.
> So this means this symbol gets the extension doubled. Also an good
> question is here why DLL contains at all symbols with @ decoration
> in e
Dear list,
As i was looking at the conversation indexed by GMane
here: http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/4888
i noticed that my answer to Kai's latest message wasn't there.
That might be due to the fact i attached a 17kB file to
my email, and it might have failed to pass
Dear list readers,
>> I'm just trying to sensitize you for the consequences of your
>> compat-breaking changes, which are the sole reason for my
>> "derecommendation".
> Consider your point made, but understand this: TDM-GCC certainly has
> some critical differences from other GCC distributions
Just for clarification: In the def file, you will see a few C-compliant
methods. These are the one i call from my main binary, along with DeviceConfig
and Config constructors and destructors.
The only other function called from the main binary is SC::StaticInitializer,
it's a static declaring it
Hmm, I doubt that the code for delay-load support makes a differenceof calling-convention of exports. Only important thing is that thosefunction are declared with proper calling-convention prototype.That's exactly what JonY told me when we attacked this problem (He was of a great help regarding th
Dear list readers,
i'm enjoying my free time to migrate all my projects on the MinGW-w64 compiler
toolchain.
i am using Ruben's build right now, and it is working exactly as expected (All
my project compile as well as the 3rd party project they need).
My goal being to achieve the same thing i wa
Dear Erik,
First of all, i really appreciate you taking time to answer me.
> The qmake build system doesn't work with build triplets, but with
> so-called mkspecs profiles. These profiles are located in the mkspecs
> folder which is part of the Qt source tarball.
Right.
> If you open the file mk
> Take a look at GNUWin32 they have a lot of the programs you'd want, for use
> with cmd. The shell remains the same old non-functional cruft, but you get
> ls, file, find, etc... Just remember GNU find is not Windows find, and some
> stuff might expect the Windows version.
Thanks for the tip!--
> Yes, you will, but depending on how you build them, you'll need to point the
> project's build infrastructure to find the Qt you've built. There's nothing
> special about MSYS, it's only an emulation of a POSIX shell on top of Windows.
Perfect. Thanks Ruben :) Just for my personal information,
> No, it's not related to the toolchain. This is Qt's configure not working on
> MSYS. Specifically, -DUNICODE is missing from the compiler options.
It's working with SeZero's build. i'm really wondering what's different in his
build.
> I must *strongly* urge you to try building Qt from cmd ins
> Yes, a Linux plus Wine (64-bit or 32-bit) is absolutely an alternative
> to cygwin/msys. It has also the advantage of the speed of Linux.
> There is also a 64-bit Wine version, not sure if it is available for
> MAC, too. I am using on my Linux-box Wine for running testsuites. Eg
> testsuite ru
Kai,
>> Creating qmake. Please wait...
>> g++ -c -o project.o -DQMAKE_OPENSOURCE_EDITION -g -I. -Igenerators
>> -Igenerators/unix -Igenerators/win32 -Igenerators/ma
>> c -Igenerators/symbian -Igenerators/integrity
>> -I/QtSDK/Desktop/Qt/4.8.1/i686-w64-mingw32/include -I/QtSDK/Desktop/Qt/4.8
>>
The last toolchain i have downloaded is the one from TDM's. i'm trying to
compile Qt 4.8.1 with it, and it fails where SeZero's build was successfull.
The error message i get is when compiling QMake (Which takes place in the
./configure part):
Creating qmake. Please wait...
g++ -c -o project.o
Hello again :)
As my easiest questions were answered flawlessly, now i am going to ask you
something that might interest you more.
I primarily do my coding on my Mac. i choose the Qt framework because my
projects have to run exactly the same on Windows, Linux and Mac OSX (At least i
use Qt for
>> - When using the Europe -> France -> Free mirror, the package
>> make-3.82-mingw32-bin.tar.lzma cannot be found on the server (404 type
>> error). Is Dragon part of this list, or is it another project mailing list i
>> shall subscribe to to report the problems i encounter?
> Hmm, I heard that so
Dear Ruben, dear list readers,
>> I suggest using a native MinGW-w64 toolchain to build Qt. Qt does not
>> support cross-compiling (just look at the OpenSuse or Fedora mingw-w64 Qt
>> package build scripts: they patch the hell out of Qt's build infrastructure).
>
> Ah! But i *am* using a native
Dear Ruben,
First, thank you very much for your kind help.
> Is there anyone here successfull in compiling Qt 4.8.1 with MinGW-w64 using
> MSys? If yes, how?
>
> No, it's not intended to be built from MSYS on windows. It might work, but is
> not recommended (by me nor Nokia). This problem thou
Hallo Kai,
> sure there are a lot of people building Qt by using mingw-w64 (for
> 32-bit and 64-bit version).
i would really be interested to know about their setup / configure options, as
the automated MinGw binary doesn't works for me.
Please note that i just have downloaded SeZero MinGW build,
Dear list readers,
As you might remember, i have been playing around with MinGW-w64 on MSys to see
if it could be of a good replacement for compiling on / for windows.
i finally have dropped the migration, as i was seriously lacking some research
time.
Now that i have a bit time for me again, i
>> Is there anyone aware of some kind of wrapper so i could use the MSVC
>> compiler with either MSYS or cygwin? By that, i mean that i have bash
>> scripts which perform under either linux, macos and windows, and i would
>> like to be able to use them as well in cohesion with the MSVC compiler.
> thank you very much for the additional info.. Yes, you are wright, I did this
> just because I wanted to see that the compiler works. My real application
> will require arguments anyway.
> Thanks a lot for your help.
No problem, glad i could help you.
Have fun!
Pierre.
--
Dear MinGW-w64 readers,
Is there anyone aware of some kind of wrapper so i could use the MSVC compiler
with either MSYS or cygwin? By that, i mean that i have bash scripts which
perform under either linux, macos and windows, and i would like to be able to
use them as well in cohesion with the M
Please post to the mailing list, if you only post to me and i answer you with a
misstake, no one will be able to correct me :)
> thank you very much for your quick response. I just tried with a "viod"
> instead and it works fine now.
You shouldn't use void as your main arguments for two reasons:
Dear JonY,
> Fastcall and stdcall are different call conventions, so don't mix them up.
i know, but i tried to see what happenned.
> Seeing your earlier gendef output, _ZN7TotoLibC1Ev@4@4 looks very wrong,
> how are you building the DLL? Maybe you can pass me the source/headers
> off-list.
i did!
i just tried replacing all __stdcall on my example by __fastcall, and rebuilt
the test library, re-made the .def / .delayed.a etc. Then the main executable
can link against the library (Although, the .def looks exactly the same to
me...), but it crashes when trying to call the dll object (My deb
Well... Bummer. In the latest version of the Toto test project, i was actually
using __stdcall. But still...
This is from TotoLib.h:
#ifndef TotoLib_h
#define TotoLib_h
#include "TotoLib_Global.h"
class TotoLibOpt TotoLib {
public:
/**/ TotoLibOpt __stdcall TotoLib();
};
#endif
This
> No, your code is requesting versions wothout @nn, but gendef is actually
> finding that the functions are adjusting the stack before returning
> (fastcall or stdcall). gendef can't tell the difference between @0 and
> cdecl though since they look the same.
> You should tell the compiler which cal
i just put the Toto test project on my mac, and compiled it. It works when
using -lazy-lTotoLib as well as when using -lTotoLib.
And if i compile TotoApp using -lazy-lTotoLib and add a debug message in the
main right before the library will get loaded, the binary executes without
dependencies pr
Oh and in the test "Toto" project, if i add --assume-stdcall to gendef for
creating the delayload lib for TotoLib, i get linker error on TotoApp:
20:31:13: Starting: "C:\MinGW\mingw-w64\bin\mingw32-make.exe"
C:/MinGW/mingw-w64/bin/mingw32-make.exe -f Makefile.Debug
mingw32-make.exe[1]: Entering
> Nope, as long as it is in C++, there is no guarantees that it will work
> with a different compiler. What you could do is to thunk the code via a
> C bridge from the MSVC side.
> eg for Simple C++:
> rettype C_Shutdown(unsigned long a){
> return Shutdown(a);
> }
> and for class/members
> rettype
JonY, you see perfectly right.
> Please check the DLL with gendef, see if the functions are mangled. Do
> you see ShutDown or something that begins with a '?'?
> If the former, you are likely missing extern "C" declarations when you
> included your vendor headers.
> If the latter, the vendor DLL i
> Are you building RELib? It should only be used when building it, not
> when using it. I have no idea what Q_DECL_EXPORT is, you'll need to give
> more information.
i am (It is one of the many binaries i maintain). i only use RELib when
building it of course.
About the Q_DECL_EXPORT macro, it get
Hello dear list readers,
This topic is a whole new one, this is on purpose, and i'd like to solve this
in parallel with the other one (Delay-loading my libraries).
In this one, it is more about loading third-party DLLs directly in my projects.
The DLLs i would like to use from my project (And i'
JonY,
> I checked it against your def file, looks like it's
> __ZNK2RE6Engine13loadedPluginsEv@4, not
> __ZNK2RE6Engine13loadedPluginsEv, I'm not sure how non-delay lib is
> linking successfully.
Thank you very much for digging further into this issue JonY.
> Did you use the proper call declarati
Dear JonY and dear users,
i have found another weird clue to my problem.
i just have tried to compile another program of our project that uses the same
library we are talking about.
When linking against the libRELibrary.a, everything is swell. But when linking
against the delay-loaded version,
Dear Kai,
> Well, that it is a bug in delayed-load code might be, but I wouldn't
> assume so. it might be more related to the issue of exporting
> variables (in C++ things like vtables, etc are variables).
All right, but in this case why is my library working in non-delayed mode? If
it was relat
Dear JonY,
> OK, so linking and running works if done without delay loading? If so,
> it might be a bug in the delay loading code.
Ok. Would you help me to solve it in the source code if it is so?
> For the linker command, show both.
Ok. Here you go:
1) This is the linker command used when compil
Dear JonY, dear list readers,Try using gendef -a, also, try using regular non-delay lib as a test.if i compile my library and then generate the .a with a def from gendef with the --assume-stdcall option, then i'm unable to link against my library.i get a lot of messages like this (When i compile a
Hello list readers,
i'm a newcomer to this list. i'm Pierre, and i've been playing with mingw-w64
for the past 3 days. i have been gathering help from the original mingw project
list, the guys were very helpfull here. So now i'm facing more mingw-w64
issues, i'm subscribing to this list upon ad
69 matches
Mail list logo
