I was interested in other's IRIX OpenDX 4.3 builds. I am using the MIPS
compiler building for n32 and mips3 and had several undefined symbols
(e.g., _S_initialize and _S_uninitialize), which I resolved by linking with
libCio. Does that sound reasonable?
I can run the sample programs fine.
I get an error when I start the VPE (with the startup or dx -edit). The
assert from List.C line 119 fails. This happens after some calls are made
from EditorWindow::createWorkArea to ToolSelector::initialize to
ToolSelector::augmentLists to ToolSelector::addTool, etc.
I plan to look into this further, but just wanted to see if anyone else was
having any problems.
Jeff
At 04:32 PM 6/2/2003 +0100, you wrote:
I've just built opendx 4.3.0, from the tar ball David Thompson provided,
on a Solaris 8 Sun Blade machine and an IRIX64 sgi Onyx 300.
The libtool method seemed to work reasonably, with tweaks similar to the
previous version required to fully build.
I used the 'configure' script supplied in the tar and did not regenerate
it.
Both systems warned about macro RAND_MAX being re-declared in a standard
library and in dxconfig.h.
Please see my OTHER BUGS bit at the end too.
Here's a summary:
IRIX64:
setenv LIBS "-ldf -lz -ljpeg -lnetcdf"
setenv CC "cc"
setenv CXX "CC"
setenv CFLAGS "-64 -O -mips4 -OPT:Olimit=0"
setenv CXXFLAGS "-64 -O -mips4 -LANG:std -OPT:Olimit=0"
setenv LDFLAGS "-64 -mips4"
setenv SGI_ABI "-64"
./configure --prefix=/tmp/opendx4.3.0 --with-large-arenas=yes
An error came up in these files:
cc-1168 CC: ERROR File = DXWindow.C, Line = 821
cc-1168 CC: ERROR File = ResourceManager.C, Line = 37
cc-1168 CC: ERROR File = ResourceManager.C, Line = 147
cc-1168 CC: ERROR File = ResourceManager.C, Line = 163
cc-1168 CC: ERROR File = ResourceManager.C, Line = 176
cc-1168 CC: ERROR File = ToolSelector.C, Line = 239
All have the same error:
The indicated type conversion is invalid.
while (s=(Symbol)iter.getNext()) {
The problem is that Symbol is of type int: (SymbolManager.h:typedef int
Symbol;) so the cast from 64-bit pointer to int fails. Replacing with
the following sorts it out:
while (s=*(Symbol*)iter.getNext()) {
(But is this what is intended?)
OTHER BUGS:
How about sorting out some other bugs before 4.3 is released : See my
bug report on isosurface.c in the bug reporting system (#100), also
Describe crashes dxexec if a 4-D variable with 'Invalid positions' is
used (example net attached). The bug is in line 600 of
src/exec/libdx/box.c. The following:
done:
if (ich)
DXFreeInvalidComponentHandle(ich);
if (box && !_copyout(box, m, box_array))
goto null_return;
return (Object) f;
null_return:
if (ich)
DXFreeInvalidComponentHandle(ich);
return NULL;
Should be replaced with:
done:
if (ich){
DXFreeInvalidComponentHandle(ich);
ich = NULL;
}
if (box && !_copyout(box, m, box_array))
goto null_return;
return (Object) f;
null_return:
if (ich)
DXFreeInvalidComponentHandle(ich);
return NULL;
The problem is that _copyout fails with 4-D data (which is a pain), then
it tries to free ich again in null_return.
Thanks,
John
