wxWidgets Discussion Forum

Well, still segfaults after an uneventful debug build: Program received signal SIGSEGV, Segmentation fault. 0xb7e64e79 in wxStandardPaths::GetInstallPrefix (this=0xbfaeea20) at ../src/unix/stdpaths.cpp:68 68 wxString basename(wxString(wxTheApp->argv[0]).AfterLast(_T('/'))); apparently while trying t...

Thanks for the speedy response, David. ::Get().GetDataDir() crashes too, though everything appears to run ok if the line is removed. But you may be on to something: make hung twice and had to be restarted when I was building wxWidgets (2.6.3 gtk also) yesterday, so I'll try and see if a rebuild clea...

Hi, I've ported/built some working win32 code in Linux but get a seg fault during execution at this line: appDir = wxStandardPaths().GetDataDir(); where gdb reports: Program received signal SIGSEGV, Segmentation fault. 0xb7e308f8 in wxStandardPaths::GetInstallPrefix () from /usr/local/lib/libwx_base...

Took me a while to check back here, but better late than never. Thanks Chris, I'll keep my eye out for a NinjaNL update.

doh now I get it! 'I64' prints out with either devpak.

Hi Chris, Cout << "wxLongLongFmtSpec" just prints 'wxLongLongFmtSpec' literally with either NinjaNL or Simon devpaks (I had to uninstall upCase, so I can't say for sure there); Whether Format crashes or just misformats varies by devpak, NinjaNL's 2.7 devpak : crash Andre Simon's 2.6.2 devpak, upCase...

There are plenty of devpaks around, Chris. The only reason to make another would be if it actually solves a problem which the others don't, so as you say determining the root cause comes first.

Bahman

Good morning Chris! Your efforts are way above and beyond the call of duty, but then sometimes one 'catches a bug'. I have upCase's 2.6.0 devpak and Andre Simon's 2.6.2 devpak . Compiling and running printf( "%" wxLongLongFmtSpec "u %s", wxULL((uint64_t)2), "hello world\n" ); cout << wxString::Forma...

Thanks ABX still outputs

2 (null)

The problem isn't that I can't display the 64 bit integer, but that the string that follows it becomes '(null)'.

Bahman

No, Format() was just my preferred method, if only because the code is more visually concise (to my eye, anyway). Going by that standard, though, plain old cout, working as it does without any addl typecasts/modifiers/overloads, looks better and better...

Thanks again
Bahman

Awesome, Chris, this is the full answer, no doubt. (The joke is I ran across -I64 yesterday, misread it as -EllSixtyFour and therefore got no result :) Unhappily although printf( "%I64u %s", (uint64_t)2, "hello world\n" ); works fine, cout << wxString::Format( "%I64u %s", (uint64_t)2, "hello world\n...

Whoops, got temporarily banned due to an administrative snafu... I'm back. Your're onto something, Chris. Printf fails on uint64_t as well, (though cout works ok); and running your code at this end (wxWidgets 2.6.0, DEV-C++ mingw32-gcc-3.4.2) gives 2 hello world 2 (null) overloaded: 2 hello world 2 ...

Hi Chris, Makes no difference, template or not. I've tried all the modifiers in simple template-free cout statements, and the 64bit type always causes the subsequent string to go '(null)'. If it's a problem with the modifier, then a typecast in the template should fix things: template<class T> void ...

To the wxperts out there, uint64_t seems to throw wxString::Format out of whack, e.g. #include <cstdlib> #include <iostream> #include <wx/string.h> using namespace std; template<class T> void echo( T i, const char *s ) { cout << wxString::Format( "%Lu %s ", i, s ) << "\n"; } int main(int argc, char ...

You pointed me in the right direction, asteelef! :D The answer turns out to be bool wxInitialize () This function is used in wxBase only and only if you don't create wxApp object at all. In this case you must call it from your main () function before calling any other wxWidgets functions. [/i] int m...