wxWidgets 2.6.3 on IRIX 6.5: windows are all black
Gary Oberbrunner
black. Here's my setup:
WX: 2.6.3
OS: IRIX 6.5
COMPILER: MIPSpro 7.4.2m (64-bit mode)
Configure: MAKE=gmake --disable-shared
I'm using the above setup, and when I build wxWidgets and the samples and run
them, they come out all black; even the 'minimal/minimal' sample. You can see
a few hilights around the edges of buttons, but it's basically unusable.
There are also layout problems (buttons in wrong places etc.) My real app
suffers in the same way.
I'm building as a static lib (--disable-shared) in case that matters.
The x11univ version works fine; unfortunately it doesn't support copy/paste
which the Motif version does, I think, and I care about that.
Is anyone having success with this type of build? Is there something in my
runtime environment perhaps that's making it not work? I also tried 2.8, but
it doesn't build on the above machine; problems with wxString i18n and others.
Any hints? Please cc ga...@genarts.com, since I'm not on this list. I
appreciate any help!
-- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
For additional commands, e-mail: wx-use...@lists.wxwidgets.org
Carl Godkin
> Hi folks. I'm having a problem where my app, and the samples, come out all
> black. Here's my setup:
>
> WX: 2.6.3
> OS: IRIX 6.5
> COMPILER: MIPSpro 7.4.2m (64-bit mode)
> Configure: MAKE=gmake --disable-shared
>
> I'm using the above setup, and when I build wxWidgets and the samples and run
> them, they come out all black; even the 'minimal/minimal' sample. You can see
> a few hilights around the edges of buttons, but it's basically unusable.
> There are also layout problems (buttons in wrong places etc.) My real app
> suffers in the same way.
>
> I'm building as a static lib (--disable-shared) in case that matters.
> The x11univ version works fine; unfortunately it doesn't support copy/paste
> which the Motif version does, I think, and I care about that.
>
> Is anyone having success with this type of build? Is there something in my
> runtime environment perhaps that's making it not work? I also tried 2.8, but
> it doesn't build on the above machine; problems with wxString i18n and others.
We used to support the SGI (IRIX 6.5 and your compiler) just fine with
wxWidgets, though we used wxGTK, not wxMotif.
The only problem I can think of that might turn all of the windows black
as you describe might be a problem with the visual. By default, you will
probably get an 8-bit PseudoColor visual which will do some weird things
relative to the other windows. I always thought it was weird that the
default was this wimpy visual instead of a 24-bit TrueColor visual like
you get from most Linux X Servers by default.
I submitted a patch to wxWidgets which has been applied for wx 2.8 (I think)
which resolves this problem, but before that we used to hack wxApp::OnInitGui()
Your problem may be different since it's Motif and 64-bit Irix and
so forth, but it sounds like a problem with the Visual. Can you try
wx 2.8.0 and see if it's better?
Good luck,
carl
Peter Gordon
m_parent->SetBackgroundColour(wxTheApp->GetTopWindow()->GetBackgroundColour()) ;
Peter
Vadim Zeitlin
GO> WX: 2.6.3
GO> OS: IRIX 6.5
GO> COMPILER: MIPSpro 7.4.2m (64-bit mode)
GO> Configure: MAKE=gmake --disable-shared
So, just to be sure, you use wxMotif, right?
GO> I'm using the above setup, and when I build wxWidgets and the samples
GO> and run them, they come out all black; even the 'minimal/minimal'
GO> sample. You can see a few hilights around the edges of buttons, but
GO> it's basically unusable. There are also layout problems (buttons in
GO> wrong places etc.) My real app suffers in the same way.
I really don't know what's going on here. All I can say is that I did test
exactly the same configuration under IRIX about a year ago and it worked
fine. So either you have different Motif resources set up or maybe the
problem is specific to 64 bit mode (I don't remember if I tested in 64
bits).
GO> Is anyone having success with this type of build? Is there something
GO> in my runtime environment perhaps that's making it not work? I also
GO> tried 2.8, but it doesn't build on the above machine; problems with
GO> wxString i18n and others.
We'd really appreciate if you could report these problems to us in details
and help with testing/fixing them. I don't have access to IRIX machine any
more unfortunately so we can't do anything about it without your help.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Vadim Zeitlin
PG> I had similar problem with HP. If fixed it with the following line:
PG>
PG> m_parent->SetBackgroundColour(wxTheApp->GetTopWindow()->GetBackgroundColour()) ;
This is really strange. What was the background colour before and what did
this change it to?
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Gary Oberbrunner
> We'd really appreciate if you could report these problems to us in details
> and help with testing/fixing them. I don't have access to IRIX machine any
> more unfortunately so we can't do anything about it without your help.
OK, sorry about that -- sometimes it's easier to just find the working version
and get on with life :-)
I configure 2.8 like this:
MAKE=gmake CFLAGS='-64' CXXFLAGS='-64' LDFLAGS='-64' \
../configure --disable-shared
and that goes OK. Then during the make phase, I get this:
cc-1020 CC: ERROR File = ../src/common/string.cpp, Line = 1728
The identifier "strtoll" is undefined.
return wxStringToIntType(c_str(), val, base, wxStrtoll);
^
cc-1020 CC: ERROR File = ../src/common/string.cpp, Line = 1740
The identifier "strtoull" is undefined.
return wxStringToIntType(c_str(), val, base, wxStrtoull);
This means wxHAS_STRTOLL is defined. In the configure output I see:
checking for strtoull... yes
but I think this is done in a .c file; it seems that function is only
available in stdlib.h from C, not C++. And nobody checks for strtoll at all,
only strtoull.
So anyway, I just #undef wxHAS_STRTOLL and wxHAS_STRTOULL in string.cpp just
to get around it. Then, after an hour or so... (SGIs are really slow...) the
next problem is when linking wxrc:
CC -o wxrc wxrc_wxrc.o -64 -L/usr/lib64
-L/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib -lz -lpthread -lm
-lwx_base_64_xml-2.8 -lwx_base_64-2.8 -lwxexpat_64-2.8 -64 -L/usr/lib64
-lz -lpthread -lm
ld64: ERROR 33 : Unresolved text symbol "wxStringToIntType(const
char*,long*,int,long (*)(const char*,char**,int))" -- 1st referenced by
/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib/libwx_base_64-2.8.a(baselib_string.o).
ld64: ERROR 33 : Unresolved text symbol "wxStringToIntType(const
char*,unsigned long*,int,unsigned long (*)(const char*,char**,int))" -- 1st
referenced by
/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib/libwx_base_64-2.8.a(baselib_string.o).
... ha ha, another string.cpp thing! It seems perhaps to be related to the
same error as before, but it's from the versions I *didn't* ifdef out, viz:
wxString::ToLong(long *val, int base) and
wxString::ToULong(unsigned long *val, int base)
so at this point I gave up, not knowing why the wxStringToIntType template
wouldn't expand into something useful. Well, OK not quite; sometimes I'm a
little tenacious. I tried setting these makefile vars:
AR='CC' AROPTIONS='-ar -o'
which SGI says will instantiate templates while creating a static archive lib.
(I had to tweak the configured Makefile, can't change AROPTIONS via configure
I think.) And sure enough it does a lot more stuff ("C++ Prelinker").
And it actually builds! But the samples still don't: I get this:
CC -o minimal minimal_minimal.o -64 -L/usr/lib64
-L/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib -lz -lpthread -lm
-lwx_motif_64_core-2.8 -lwx_base_64-2.8 -L/usr/Motif-2.1/lib64 -lSgm
-lXm -lXmu -lXext -lXt -lX11 -lXext -lSM -lpng -lz -ljpeg -ltiff
-lwxexpat_64-2.8 -64 -L/usr/lib64 -lz -lpthread -lm
ld64: ERROR 33 :
Unresolved text symbol "XmRenditionCreate" -- 1st referenced by
/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib/libwx_motif_64_core-2.8.a(corelib_font.o).
which is weird because that symbol should be defined in libXm.so (and it is).
-- Gary
Vadim Zeitlin
GO> OK, sorry about that -- sometimes it's easier to just find the working
GO> version and get on with life :-)
But the problem is that it's also much easier for us to fix the bug in the
latest version [only] and so this means that you will have difficulties
upgrading later. IOW it may take more time right now but it saves more in
the future.
GO> This means wxHAS_STRTOLL is defined. In the configure output I see:
GO> checking for strtoull... yes
GO> but I think this is done in a .c file; it seems that function is only
GO> available in stdlib.h from C, not C++.
Hmm, I do wonder how/why does it happen. Could you please have a look at
stdlib.h?
GO> And nobody checks for strtoll at all, only strtoull.
Yes, the assumption is that if strtoull() is provided, then strtoll() is
as well. It would be really strange if it were otherwise.
GO> So anyway, I just #undef wxHAS_STRTOLL and wxHAS_STRTOULL in string.cpp just
GO> to get around it. Then, after an hour or so... (SGIs are really slow...)
The one I used was the fastest machine I ever built wx on: the full build
took slightly more than a minute. Of course, it probably helped that it had
32 CPUs :-)
GO> so at this point I gave up, not knowing why the wxStringToIntType template
GO> wouldn't expand into something useful. Well, OK not quite; sometimes
GO> I'm a little tenacious. I tried setting these makefile vars:
GO> AR='CC' AROPTIONS='-ar -o'
GO> which SGI says will instantiate templates while creating a static
GO> archive lib.
It looks like it needs the same treatment as Sun CC. Would you know if
this is needed for static libraries only or shared ones too? And/or any
links to SGI documentation for this?
GO> But the samples still don't: I get this:
GO>
GO> CC -o minimal minimal_minimal.o -64 -L/usr/lib64
GO> -L/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib -lz -lpthread -lm
GO> -lwx_motif_64_core-2.8 -lwx_base_64-2.8 -L/usr/Motif-2.1/lib64 -lSgm
GO> -lXm -lXmu -lXext -lXt -lX11 -lXext -lSM -lpng -lz -ljpeg -ltiff
GO> -lwxexpat_64-2.8 -64 -L/usr/lib64 -lz -lpthread -lm
GO>
GO> ld64: ERROR 33 :
GO> Unresolved text symbol "XmRenditionCreate" -- 1st referenced by
GO> /disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib/libwx_motif_64_core-2.8.a(corelib_font.o).
GO>
GO> which is weird because that symbol should be defined in libXm.so (and it is).
And is libXm.so in /usr/Motif-2.1/lib64?
Thanks,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Gary Oberbrunner
> GO> This means wxHAS_STRTOLL is defined. In the configure output I see:
> GO> checking for strtoull... yes
> GO> but I think this is done in a .c file; it seems that function is only
> GO> available in stdlib.h from C, not C++.
>
> Hmm, I do wonder how/why does it happen. Could you please have a look at
> stdlib.h?
It's explicit there:
#if defined(__c99) || ((_SGIAPI || _ABIAPI) && _NO_ANSIMODE)
extern long long strtoll(const char * __restrict, char ** __restrict, int);
#endif /* __c99 || _SGIAPI || _ABIAPI */
> GO> I'm a little tenacious. I tried setting these makefile vars:
> GO> AR='CC' AROPTIONS='-ar -o'
> GO> which SGI says will instantiate templates while creating a static
> GO> archive lib.
>
> It looks like it needs the same treatment as Sun CC. Would you know if
> this is needed for static libraries only or shared ones too? And/or any
> links to SGI documentation for this?
I think you're right, looking at the configure code. It's static libs only,
since shared libs are linked with CC (so they already get the prelinking
step). See 'man CC' here:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/cc.z
(or here: http://tinyurl.com/y5umxq) and look for "-ar".
> GO> But the samples still don't: I get this:
> GO>
> GO> CC -o minimal minimal_minimal.o -64 -L/usr/lib64
> GO> -L/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib -lz -lpthread -lm
> GO> -lwx_motif_64_core-2.8 -lwx_base_64-2.8 -L/usr/Motif-2.1/lib64 -lSgm
> GO> -lXm -lXmu -lXext -lXt -lX11 -lXext -lSM -lpng -lz -ljpeg -ltiff
> GO> -lwxexpat_64-2.8 -64 -L/usr/lib64 -lz -lpthread -lm
> GO>
> GO> ld64: ERROR 33 :
> GO> Unresolved text symbol "XmRenditionCreate" -- 1st referenced by
> GO> /disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib/libwx_motif_64_core-2.8.a(corelib_font.o).
> GO>
> GO> which is weird because that symbol should be defined in libXm.so (and it is).
>
> And is libXm.so in /usr/Motif-2.1/lib64?
Well, yes -- but it is also in /usr/lib64! But that one does *not* have
XmRenditionCreate. Hmm. So I'm probably getting the wrong one. Tweaking the
link order (removing the extra -L/usr/lib64 at the beginning) makes the sample
link. Progress! But then it crashes when run. Apologies for the terrible
line wrapping. Some of the 0x1s here look like bad pointers to me.
Specifically look at the call to wxFrameBase::CreateStatusBar; should the
const wxString& arg really be 0x1?
(dbx) where
> 0 XmbTextExtents(0x1054f328, 0x10554bb0, 0x1, 0xffffffa910, 0x1, 0x0, 0x73,
0xffffffffffffffff) ["/xlv42/6.5.23m/work/x/xc/lib64/X11/FSWrap.c":181, 0x219e9f8]
1 ::wxGetTextExtent(void*,const wxFont&,double,const
wxString&,int*,int*,int*,int*)(0x1054f328, 0x10554bb0, 0x1, 0xffffffa910, 0x1,
0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/src/motif/font.cpp":662, 0x100f3b88]
2 wxWindowDC::DoGetTextExtent(const wxString&,int*,int*,int*,int*,wxFont*)
const(0xffffffa9b0, 0xffffffaba0, 0x0, 0xffffffaba8, 0x1, 0x0, 0x73,
0xffffffffffffffff) ["/disk2/tmp/wxWidgets-2.8.0/src/motif/dcclient.cpp":1312,
0x1014fe20]
3 wxStatusBar::Create(wxWindow*,int,long,const wxString&)(0x10552c58,
0x10554bb0, 0x1, 0xffffffa910, 0x1, 0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/include/wx/dc.h":442, 0x10175204]
4 wxStatusBar::wxStatusBar(wxWindow*,int,long,const wxString&)(0x1054f328,
0x10554bb0, 0x0, 0x10010, 0x1, 0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/include/wx/generic/statusbr.h":33, 0x101330cc]
5 wxFrameBase::OnCreateStatusBar(int,long,int,const wxString&)(0x105180b0,
0x10554bb0, 0x10010, 0x0, 0x1, 0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/src/common/framecmn.cpp":326, 0x10131c6c]
6 wxFrameBase::CreateStatusBar(int,long,int,const wxString&)(0x105180b0,
0x10554bb0, 0x1, 0xffffffa910, 0x1, 0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/src/common/framecmn.cpp":316, 0x10131bc4]
7 MyFrame::MyFrame(const wxString&)(0x105180b0, 0xffffffae48, 0x1,
0xffffffa910, 0x1, 0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/samples/minimal/minimal.cpp":172, 0x100c694c]
8 MyApp::OnInit(void)(0x1054f328, 0x10554bb0, 0x1, 0xffffffa910, 0x1, 0x0,
0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/samples/minimal/minimal.cpp":128, 0x100c647c]
9 wxAppConsole::CallOnInit(void)(0x1054f328, 0x10554bb0, 0x1, 0xffffffa910,
0x1, 0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/include/wx/app.h":76, 0x100c3314]
10 ::wxEntry(int&,char**)(0x1054f328, 0x10554bb0, 0x1, 0xffffffa910, 0x1,
0x0, 0x73, 0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/src/common/init.cpp":424, 0x1030521c]
11 ::main(0x1, 0x10554bb0, 0x1, 0xffffffa910, 0x1, 0x0, 0x73,
0xffffffffffffffff)
["/disk2/tmp/wxWidgets-2.8.0/samples/minimal/minimal.cpp":109, 0x100c1db0]
12 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_64_M4/csu/crt1text.s":177,
0x100c1a88]
Any idea where I should go from there?
-- Gary
Gary Oberbrunner
> ... Tweaking the
> link order (removing the extra -L/usr/lib64 at the beginning) makes the sample
> link. Progress! But then it crashes when run.
One more thing: if I ifdef out the status bar part of the sample, it does link
and run... but it's still all black. Just like 2.6.3. :-(
And yes, it does look like a Visual problem; xwininfo says it's running in an
8-bit pseudocolor visual; my guess is a 24-bit TrueColor would be better.
Anyone know how to change that?
Vadim Zeitlin
GO> > Hmm, I do wonder how/why does it happen. Could you please have a look at
GO> > stdlib.h?
GO>
GO> It's explicit there:
GO>
GO> #if defined(__c99) || ((_SGIAPI || _ABIAPI) && _NO_ANSIMODE)
GO> extern long long strtoll(const char * __restrict, char ** __restrict, int);
GO> #endif /* __c99 || _SGIAPI || _ABIAPI */
Ok, I've changed configure to use C++ compiler for this test, thanks.
GO> > GO> I'm a little tenacious. I tried setting these makefile vars:
GO> > GO> AR='CC' AROPTIONS='-ar -o'
GO> > GO> which SGI says will instantiate templates while creating a static
GO> > GO> archive lib.
GO> >
GO> > It looks like it needs the same treatment as Sun CC.
And did this too.
GO> > GO> But the samples still don't: I get this:
GO> > GO>
GO> > GO> CC -o minimal minimal_minimal.o -64 -L/usr/lib64
GO> > GO> -L/disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib -lz -lpthread -lm
GO> > GO> -lwx_motif_64_core-2.8 -lwx_base_64-2.8 -L/usr/Motif-2.1/lib64 -lSgm
GO> > GO> -lXm -lXmu -lXext -lXt -lX11 -lXext -lSM -lpng -lz -ljpeg -ltiff
GO> > GO> -lwxexpat_64-2.8 -64 -L/usr/lib64 -lz -lpthread -lm
GO> > GO>
GO> > GO> ld64: ERROR 33 :
GO> > GO> Unresolved text symbol "XmRenditionCreate" -- 1st referenced by
GO> > GO> /disk2/tmp/wxWidgets-2.8.0/build-motif-64/lib/libwx_motif_64_core-2.8.a(corelib_font.o).
GO> > GO>
GO> > GO> which is weird because that symbol should be defined in libXm.so (and it is).
GO> >
GO> > And is libXm.so in /usr/Motif-2.1/lib64?
GO>
GO> Well, yes -- but it is also in /usr/lib64!
On the system I used they were just symlinks to each other (although I
don't remember in which order). I wonder why do you have 2 of them and,
especially, why are they different. Do you have any way of determining
where did the files come from (i.e. package manager or something like
that)?
GO> But then it crashes when run. Apologies for the terrible line
GO> wrapping. Some of the 0x1s here look like bad pointers to me.
GO> Specifically look at the call to wxFrameBase::CreateStatusBar; should
GO> the const wxString& arg really be 0x1?
No. Unfortunately it's really difficult to understand what's going on
without debug info. Would it be possible for you to build with
--enable-debug? Note that it should also build much quicker (because
optimisations are disabled in debug build). And, of course, it would help
to debug the problem with the incorrect visual being used too.
Thanks,
VZ
Gary Oberbrunner
> On Wed, 10 Jan 2007 09:40:29 -0500 Gary Oberbrunner <ga...@genarts.com> wrote:
> GO> > And is libXm.so in /usr/Motif-2.1/lib64?
> GO>
> GO> Well, yes -- but it is also in /usr/lib64!
>
> On the system I used they were just symlinks to each other (although I
> don't remember in which order). I wonder why do you have 2 of them and,
> especially, why are they different. Do you have any way of determining
> where did the files come from (i.e. package manager or something like
> that)?
Tracked this down. Basically I seem to have two different Motif versions;
they're both installed by the same swmgr product:
% showfiles -- /usr/lib64/libXm*
f 38107 3475736 motif_eoe.sw64.eoe usr/lib64/libXm.so.1
f 32024 4746936 motif_eoe.sw64.eoe usr/lib64/libXm.so.2
The problem comes from the fact that /usr/lib64/libXm.so is a symlink to the
.1 version, and /usr/Motif-2.1/lib64/libXm.so is a symlink to the .2 version.
Both versions, and both symlinks, come from motif_eoe.sw64.eoe.
For completeness, here's the install record:
% versions motif_eoe.sw64.eoe
Name Date Description
I motif_eoe 05/11/2004 IRIX IM Execution Software (Motif 1.2 and
2.1 Combined) for 6.5.23
I motif_eoe.sw64 05/11/2004 Execution Only Envirnment Software
I motif_eoe.sw64.eoe 05/11/2004 Shared Libraries
> GO> But then it crashes when run. Apologies for the terrible line
> GO> wrapping. Some of the 0x1s here look like bad pointers to me.
> GO> Specifically look at the call to wxFrameBase::CreateStatusBar; should
> GO> the const wxString& arg really be 0x1?
>
> No. Unfortunately it's really difficult to understand what's going on
> without debug info. Would it be possible for you to build with
> --enable-debug? Note that it should also build much quicker (because
> optimisations are disabled in debug build). And, of course, it would help
> to debug the problem with the incorrect visual being used too.
I now don't think it's the visual (or not just that). I switched my X server
so the default visual is 24/truecolor, and that does get used by the minimal
sample, but it still comes out black.
I'll do a debug build & see what I can learn.
-- Gary
Gary Oberbrunner
> On Wed, 10 Jan 2007 09:40:29 -0500 Gary Oberbrunner <ga...@genarts.com> wrote:
> GO> wrapping. Some of the 0x1s here look like bad pointers to me.
>
> without debug info. Would it be possible for you to build with
> --enable-debug?
OK. Here's the debug stack trace:
(dbx) where
> 0 XmbTextExtents(0x10792d30, 0x10798e08, 0x1, 0xffffffa7e8, 0x1, 0x0, 0x73,
0xffffffffffffffff) ["/xlv42/6.5.23m/work/x/xc/lib64/X11/FSWrap.c":181, 0x219e9f8]
1 ::wxGetTextExtent(void*,const wxFont&,double,const
wxString&,int*,int*,int*,int*)(display = 0x10744ae0, font = 0xffffffaa00,
scale = 1.0, str = 0xffffffaae0, width = (nil), height = 0xffffffaae8, ascent
= (nil), descent = (nil))
["/disk2/tmp/wxWidgets-2.8.0/src/motif/font.cpp":662, 0x101255f8]
2 wxWindowDC::DoGetTextExtent(const wxString&,int*,int*,int*,int*,wxFont*)
const(this = 0xffffffa900, string = 0xffffffaae0, width = (nil), height =
0xffffffaae8, descent = (nil), externalLeading = (nil), font = (nil))
["/disk2/tmp/wxWidgets-2.8.0/src/motif/dcclient.cpp":1312, 0x101d47bc]
3 wxDCBase::GetTextExtent(const wxString&,int*,int*,int*,int*,wxFont*)
const(this = 0xffffffa900, string = 0xffffffaae0, x = (nil), y = 0xffffffaae8,
descent = (nil), externalLeading = (nil), the\
Font = (nil)) ["/disk2/tmp/wxWidgets-2.8.0/include/wx/dc.h":442, 0x10219a2c]
4 wxStatusBar::Create(wxWindow*,int,long,const wxString&)(this =
0x10796660, parent = 0x1075bb30, id = 0, style = 589840, name = 0xffffffaca0)
["/disk2/tmp/wxWidgets-2.8.0/src/generic/statusbr.cpp":90, 0x10217f88]
...
The 1-char string looks OK in ::wxGetTextExtent:
p *str
class wxString {
m_pchData = 0x10798e08 = "X"
but I think the font has been freed or the font set is not set up. fset
points to null:
(dbx) fset/4x
fset/4x
10792d30: 0000 0000 0000 0000
Hope that helps...
-- Gary
Gary Oberbrunner
> GO> > It looks like it needs the same treatment as Sun CC.
>
> And did this too.
Great -- do notice that it's "-ar", not exactly like Sun CC (-xar).
Just thought I'd update you on progress: the 32 bit version works fine; both
the status bar string crash problem and the all-black problem go away.
So the remaining problems, after the ones you already fixed, are 64-bit only.
Unfortunately I haven't time enough to debug them right now.
Motif 2.1 Universal
----------- ----------------
n32 Works OK Works OK
64 text extent crash Works OK
and black
-- Gary
Vadim Zeitlin
GO> So the remaining problems, after the ones you already fixed, are 64-bit only.
GO> Unfortunately I haven't time enough to debug them right now.
I understand but I have really no idea about what's going on with the 64
bit build. Maybe some of the casts that wxMotif code is littered with go
wrong but there is really no way to know without testing. If you still have
some time to spend on this, please try to put a breakpoint on
wxFont::GetFontSet() and check what happens there when it's called from
wxGetTextExtent().
Thanks,
VZ