2011/5/9 Ruben Van Boxem <[email protected]>: > 2011/5/9 K. Frank <[email protected]> >> >> Hello Ruben! >> >> On Mon, May 9, 2011 at 3:34 AM, Ruben Van Boxem >> <[email protected]> wrote: >> > Op 9 mei 2011 00:16 schreef "K. Frank" <[email protected]> het >> > volgende: >> > ... >> >> > On the other hand, why rebuild what you already have? Only reason >> >> > would >> >> > be >> >> > optimization, but I wouldn't bother. You should be able to use the >> >> > new >> >> > GCC >> >> > version to link the older libraries. Just use the new compiler for >> >> > your >> >> > current project, using prebuilt libs. >> >> >> >> My current "everyday" installation of Qt (and some other small >> >> libraries) >> >> was built with a tdm mingw32 gcc build: >> >> >> >> g++ --version: g++ (TDM-2 mingw32) 4.4.1 >> >> >> >> I just sort of assumed that I wouldn't be able to mix my current >> >> (tdm 4.4.1) Qt libraries with code compiled with the new compiler. >> >> Do I understand you correctly that they should be compatible? >> >> (By the way, my tdm gcc uses sjlj exceptions.) >> > >> > Ah yes, I believe tdm uses the MinGW.org runtime, so compatibility >> > between >> > my mingw-w64 based toolchains and yours would not be guaranteed. >> >> Thanks for the heads-up. If and when I decide to upgrade, I will plan on >> rebuilding Qt. >> >> > ... >> > I would like to upload my Qt >> > Builds, but they are very hard, if not impossible to get relocatable. >> >> I assume that by relocatable, you mean being able to move the Qt >> installation from one location to another in the file-system directory >> hierarchy. >> >> Yes, this issue bit me once, and I ended up rebuilding Qt as the most >> convenient solution. >> >> I believe that there was a discussion on the Qt-interest list about this >> (speaking from memory), and that the Qt developers' stance was that >> this non-relocatability is a feature, and it didn't seems that there was >> any likelihood it would be changed. I honestly never understood the >> reasoning behind this. >> >> > Perhaps someone knows of a way better than the google code project which >> > tried to get it right some time ago? >> >> I seem to recall that in the list discussion, someone mentioned a tool >> that relocates a Qt installation by editing the hard-coded path names >> in the executables. >> >> > How does Nokia make its SDK installer? >> >> I also seem to recall someone saying that the Nokia installer worked >> in essentially the same way as the above-mentioned tool: that the >> executables had their hard-coded path names (or perhaps placeholders) >> edited upon installation to descend from the desired root directory for >> the installation. >> >> Again, this is from memory -- sorry if this is bogus information. >> >> I expect that a number of people would find it a valuable service, were >> you to solve the relocation issue and make available your Qt builds. >> (I know I would.) But your gcc builds are already a huge contribution, >> and probably the more important piece of the puzzle. > > Yeah, it's still the mess I'd though it was :). I read those discussions a > long time ago, and frankly, their reasoning makes no sense at all. Windows > != Unix, 'nuff said. > > Just FYI, I just rebuilt Qt 4.7 (git branch) with my GCC 4.6.1 (prerelease) > toolchain and everything went fine. I also built Qt Creator and works just > as nice as the old one I had compiled with Sezero's GCC 4.5.2 toolchain. > > Just remember to configure with (when you do, of course) > > -qt-style-windowsxp -qt-style-windowsvista -phonon > > The first two tell Qt you do have the headers for Windows XP+ window > decorations and widgets (or else you'll get the ugly win95 style for all > your Qt apps), the latter to tell Qt you've got the headers required for > phonon+DShow backend. > >> Thanks again for your contributions and all of your help. > > No problem at all, I was just frustrated there was no non-autobuild of GCC > 4.6 on the mingw-w64 site, and put myself to learning some Bash :P > > Ruben > >> >> K. Frank >>
Hmm, is it possible to get a stack-trace for ld's plugin crash? This might be pretty helpful to know at what point it crashes. As I don't see this issue I assume it is mingw-.host only related, so a stack-trace would be kind. Regards, Kai ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
