-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't install under Windows 7: std::bad_alloc #25
Comments
I'm pretty sure this is the same hang-up that everyone else has encountered On Tue, Jul 8, 2014 at 6:58 AM, Tomas Sieger notifications@github.com
|
At some point I should sit down and run the generator through valgrind. Hopefully something pops up. |
You mean running through valgrind under wine? (AFAIK valgrind does not run under windows.) Or do you hope for a catch under linux/Mac? |
Sorry, I guess I was wrong about this being the same issue as on Windows. The Windows error happens much later, and appears to be due to memory corruption. That's the one I wanted to find with valgrind (and according to the mailing list, the crash does sometimes happen on Linux). But this issue does seem like something to do with the linking. |
I solved it. The problem was that following the Win32 cranvas installation instructions (https://github.com/ggobi/cranvas/wiki/Installation-under-windows-32-bit) I was using g++ from RTools, which apparently did not work for me. I finally managed to compile qtbase using MinGW g++. Maybe, this should be mentioned in the installation instructions? However, even though qtbase can be compiled and loaded, it is unstable: see #28. |
Since you're all setup, would you please try this with the Qt5 branch? I'll look into the instability issues, but it would be great if we could get qt5 working on Windows. |
I tried building the Qt5 branch against
When running the generator from the command line, Windows helped by saying that the problem was that some entry point was missing from libstd-c++. Okay, Qt was built with mingw4.8.? and I was using mingw4.8.1 to build qtbase -maybe there was a mingw version mismatch. Then I noticed Qt comes with its copy of mingw 4.8.0. So, using that mingw 4.8.0 to build qtbase helped - the generator could be run. However, it failed with:
The same applies to Qt5.2.0. BTW the relevant "method" is probably meant to be a char constructor of a private member:
|
This is the same exact error that I have hit. Since it's always the same method (QLatin1Char::ch), I'm now thinking it might be simpler to solve than what I had originally expected (some sort of internal corruption). The smoke generator adds methods for accessing non-private fields. In this case, something has gone wrong, because the 'ch' field is private, as you pointed out. Also, it is werd that the type is an empty string. At least on my Linux machine, no accessor for "ch" is generated. I guess one approach would be check whether the smoke generator at least parses the header correctly, i.e, that the private flag is seen, but then lost somehow. |
The problem seems to be related not to whether the "char ch" is private or not, but to the fact that on Windows (not on Linux), the parser confuses the QLatin1Char constructor It leads calling the GeneratorVisitor to process the method decl "ch(c)", for which the type compiler does not return a valid type. It is not clear to me why the parser gets confused on Win, but not on Linux. The DefaultVisitor::visitClassSpecifier's node->member_specs (each line represents a single spec) differ as well:
linux:
Full commented back trace follows. The top-most frame refers to GeneratorVisitor::visitDeclarator() in which the method "ch(c)" gets no return type. Note the frame #7, in which Lines "[number]:[decl]" refer to the parser dump; I copied relevant portions of the parsed stream below each stack frame to ease undertanding.
Do you think that the parser can simply be confused by |
Wow, this is seriously impressive debugging work. We're really in debt to you. There is a preprocessor built into the generator, so it should resolve |
I checked in a couple of recent fixes to smokegen from the kde-bindings repository. Not sure if these will help at all. |
Thanks. I will check whether these kde-bindings fixes change something. Getting back to your suggestions regarding the i) My linux
Win are missing ii) defining This helps - now the generator processes everything! However, the generated sources do not compile, as the generated
On linux, the For completeness, the compiler output follows:
As the |
Looks like the preprocessor might be broken somehow on Windows. No easy way to workaround this one, so we'll have to fix it. |
Believe it or not, the two fixes taken from kde-bindings repository solved all the generator/preprocessor issues we've faced so far! The next issue was that
It was caused by undefined
My hack was to define BTW, note the warning:
Having
The culprit of the
Next, I run into:
Do you think these linking problems could be related to the missing |
It looks like we need to play with the For the intiial duplicate symbol problem, try passing |
Thanks for the fixes - they seemed to resolve the relevant problems. For the duplicate symbol problem: it seems that the duplicated symbols come from
While I can't list symbols in Regarding the undefined symbols, I don't think that I'm using 64bit g++. My g++ resides in
Also, |
The The cmake |
Preventing
So I removed all the Then I could not compile:
which could be solved by adding Then I compiled and linked, but could not load the library:
It seemed to have been caused by more versions of Qt installed (even though only 5.2.0 was on the PATH). (I'm persisting all the problems I encounter in order to possibly help others (running into same problems) making qtbase running on windows, or simply to support writing some more detailed installation instructions.) Finally, I ended with:
Don't know what it means - shall I download some extra libraries? What would be the best solution to the Qt modules problem? |
For now, we are going to have to just disable those modules on Windows, though we may want to take a close look at how that linker path is constructed (we ended up with something pretty messy). I think the missing symbol at the end is related to the defs file. Does it list |
The defs file contained no symbols. The problem was that there were extra
such that taking the Removing the extra |
Thanks. This is promising. Please submit a PR for anything you've fixed. If there are things that need to be fixed by me, submit a separate issue for each (for example, the fact that you had to disable some modules). I'm going to close this one. Thanks so much for your help! |
Following https://github.com/ggobi/cranvas/wiki/Installation-under-windows-32-bit,
qtbase build terminates with:
version info:
R version 3.1.0 (2014-04-10)
Platform: i386-w64-mingw32/i386 (32-bit)
cmake 2.8.11
Qt opensource 4.8.6
RTools 3.1 (gcc 4.6.3)
build log:
BTW note the warning:
This seems it can be fixed by
#include "rpp/pp-environment.h"
instead of the forward declaration ofnamespace rpp { class MacroBlock; class LocationTable; }
inqtbase/kdebindings/generator/parser/parsesession.h
. However, it is marginal, as it does not solve the "std::bad_alloc" problem.The text was updated successfully, but these errors were encountered: