Problem with VTK on Compaq SC45/OSF1

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with VTK on Compaq SC45/OSF1

Randall Hand
I've been working on this for 2 days, and I'm running out of ideas.  I can compile VTK just fine on our SC45, no errors at all, using cxx/cc and Shared libraries.  I can compile applications that use these freshly compiled VTK libraries just fine, with no errors.

But every time I try to run them I get the following error:
emerald0> ./vtk2xml
resolve_symbols: loader error: dlopen: libvtkVolumeRendering.so: symbol "__array_new2" unresolved

I've tried compiling them as static, and while they compile just fine, when apps try to link against them I get errors about no table of contents on every single .a file.  Anyone have any idea what's going on here?  I'm using Cmake 2.0p6, as there are no binaries provided for 2.2.3 and the bootstrap won't work.

--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: http://www.yeraze.com
_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers
Reply | Threaded
Open this post in threaded view
|

Re: Problem with VTK on Compaq SC45/OSF1

Randall Hand
Did some more investigating (I'm learning alot more about dynamic linking than I ever wanted to know).

emerald0> ldd -r ezVizGeneric (ezVizGeneric is the real program I want to compile, loooots of linked libraries)
Unresolved symbol in libvtkVolumeRendering.so: __array_new2
Unresolved symbol in libvtkGraphics.so: __array_new2
Unresolved symbol in libvtkImaging.so: __array_new2
Unresolved symbol in libvtkCommon.so: __array_new2

emerald0> ldd -r vtk2xml  (Simpler program, fewer libraries but all of VTK)
Unresolved symbol in libvtkVolumeRendering.so: __array_new2
Unresolved symbol in libvtkGraphics.so: __array_new2
Unresolved symbol in libvtkImaging.so: __array_new2
Unresolved symbol in libvtkCommon.so: __array_new2

emerald0> ldd -r main (Simplest program, direct link to only VTK, not ezViz or Xdmf/Xmdf or any of that)
Unresolved symbol in libvtkGraphics.so: __array_new2
Unresolved symbol in libvtkImaging.so: __array_new2
Unresolved symbol in libvtkCommon.so: __array_new2

So has somethign changed in the 5.0 VTK branch that would cause this kind of problem?  I seem to remember some discussion of now using "new/delete" instead of "malloc/free" in the DataArray stuff.  Is this related?

On 2/23/06, Randall Hand <[hidden email]> wrote:
I've been working on this for 2 days, and I'm running out of ideas.  I can compile VTK just fine on our SC45, no errors at all, using cxx/cc and Shared libraries.  I can compile applications that use these freshly compiled VTK libraries just fine, with no errors.

But every time I try to run them I get the following error:
emerald0> ./vtk2xml
resolve_symbols: loader error: dlopen: libvtkVolumeRendering.so: symbol "__array_new2" unresolved

I've tried compiling them as static, and while they compile just fine, when apps try to link against them I get errors about no table of contents on every single .a file.  Anyone have any idea what's going on here?  I'm using Cmake 2.0p6, as there are no binaries provided for 2.2.3 and the bootstrap won't work.

--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: <a href="http://www.yeraze.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.yeraze.com



--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: http://www.yeraze.com
_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers
Reply | Threaded
Open this post in threaded view
|

Re: Problem with VTK on Compaq SC45/OSF1

William A. Hoffman
In reply to this post by Randall Hand
At 12:01 PM 2/23/2006, Randall Hand wrote:
>I've been working on this for 2 days, and I'm running out of ideas.  I can compile VTK just fine on our SC45, no errors at all, using cxx/cc and Shared libraries.  I can compile applications that use these freshly compiled VTK libraries just fine, with no errors.
>
>But every time I try to run them I get the following error:
>emerald0> ./vtk2xml
>resolve_symbols: loader error: dlopen: libvtkVolumeRendering.so: symbol "__array_new2" unresolved

Have you sniffed around the system with nm, strings, and grep to find out if/where __array_new2 is
defined?

>I've tried compiling them as static, and while they compile just fine, when apps try to link against them I get errors about no table of contents on every single .a file.  Anyone have any idea what's going on here?\

Sounds like ranlib is not being run.

>  I'm using Cmake 2.0p6, as there are no binaries provided for 2.2.3 and the bootstrap won't work

Why won't 2.2.3 bootstrap?  What errors are you getting?  I would recommend building cmake,
and running its tests, because if they are not working, then VTK most likely will not work.

We used to have OSF dashboards, but the contributors stopped submitting them.
I am not surprised that it is not working.   If you have access to one of these
machines, and would like VTK/CMake to work on it, I can help you, but in return I would
request that you set up a dashboard and submit nightly.  Otherwise, it is a waste of time, since
it will be broken a few months from now with some other problem.

-Bill


_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers
Reply | Threaded
Open this post in threaded view
|

Re: Problem with VTK on Compaq SC45/OSF1

Randall Hand
well, "__array_new2" isn't defined anywhere.. I've grep'ed my entire source tree (VTK, Mesa, ezViz, Xdmf, Xmdf, & HDF5) and it's nowhere to be found.  NM isn't very helpful either:

emerald0> nm *.so | grep __array_new2
                 U __array_new2
                 U __array_new2
                 U __array_new2
                 U __array_new2
                 U __array_new2

Right now i'm operating on the assumption that "__array_new2" is actually a mangled version of someone's "new" operator.  I just don't know who, nor do I know how to find out.

As for CMake, I've tried several times to get 2.2.3 to work but it fails for a wide variety of reasons.  the GNU compilers are "broken" on this machine (compiling with g++ give IOT/Abort Traps) so I have to use the Vendor compilers from HP.  "Bootstrap" probably isn't the right word, because ./configure will run just fine if I set my CC=cc & CXX=cxx beforehand.  It's during the "make" that it fails.  From the last attempt:

emerald0> gmake
Scanning dependencies of target cmsys
Building C object Source/kwsys/CMakeFiles/cmsys.dir/ProcessUNIX.o
Building C object Source/kwsys/CMakeFiles/cmsys.dir/Base64.o
Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/Directory.o
Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.o
Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.o
Building CXX object Source/kwsys/CMakeFiles/cmsys.dir/CommandLineArguments.o
Linking CXX static library libcmsys.a
Scanning dependencies of target cmsys_c
Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/ProcessUNIX.o
Building C object Source/kwsys/CMakeFiles/cmsys_c.dir/Base64.o
Linking C static library libcmsys_c.a
Scanning dependencies of target testCommandLineArguments
Building CXX object Source/kwsys/CMakeFiles/testCommandLineArguments.dir/testCommandLineArguments.o
Linking CXX executable ../../bin/testCommandLineArguments
ld:
Unresolved:
cmsys::CommandLineArguments::CommandLineArguments(void)
cmsys::CommandLineArguments::Initialize(int, char**)
cmsys::CommandLineArguments::SetClientData(void*)
cmsys::CommandLineArguments::SetUnknownArgumentCallback(int (*)(const char*, void*))
cmsys::CommandLineArguments::AddArgument(const char*, cmsys::ArgumentTypeEnum, int*, const char*)
cmsys::CommandLineArguments::AddArgument(const char*, cmsys::ArgumentTypeEnum, double*, const char*)
cmsys::CommandLineArguments::AddArgument(const char*, cmsys::ArgumentTypeEnum, char**, const char*)
cmsys::CommandLineArguments::AddArgument(const char*, cmsys::ArgumentTypeEnum, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, const char*)
cmsys::CommandLineArguments::AddArgument(const char*, cmsys::ArgumentTypeEnum, bool*, const char*)
cmsys::CommandLineArguments::AddBooleanArgument(const char*, bool*, const char*)
cmsys::CommandLineArguments::AddBooleanArgument(const char*, int*, const char*)
cmsys::CommandLineArguments::AddCallback(const char*, cmsys::ArgumentTypeEnum, int (*)(const char*, const char*, void*), void*, const char*)
cmsys::CommandLineArguments::Parse(void)
cmsys::CommandLineArguments::~CommandLineArguments(void)
gmake[2]: *** [bin/testCommandLineArguments] Error 1
gmake[1]: *** [Source/kwsys/CMakeFiles/testCommandLineArguments.dir/all] Error 2
gmake: *** [all] Error 2
emerald0>



As for a Dashboard, I don't have any problem with setting one up but there's a few "gotcha"'s there.  This machine is only supposed to be here for another 4 months or so, plus due to the location there's lots of security things that might prevent me from doing it.  Also, it would need to be able to run on a headless system without X or Graphics Hardware (X is installed, but not running).  If it will run, I don't see any reason why I can't manually kick it off at nights, at least as long as we have the machine to test it on.


On 2/23/06, William A. Hoffman <[hidden email]> wrote:
At 12:01 PM 2/23/2006, Randall Hand wrote:
>I've been working on this for 2 days, and I'm running out of ideas.  I can compile VTK just fine on our SC45, no errors at all, using cxx/cc and Shared libraries.  I can compile applications that use these freshly compiled VTK libraries just fine, with no errors.
>
>But every time I try to run them I get the following error:
>emerald0> ./vtk2xml
>resolve_symbols: loader error: dlopen: libvtkVolumeRendering.so: symbol "__array_new2" unresolved

Have you sniffed around the system with nm, strings, and grep to find out if/where __array_new2 is
defined?

>I've tried compiling them as static, and while they compile just fine, when apps try to link against them I get errors about no table of contents on every single .a file.  Anyone have any idea what's going on here?\

Sounds like ranlib is not being run.

>  I'm using Cmake 2.0p6, as there are no binaries provided for 2.2.3 and the bootstrap won't work

Why won't 2.2.3 bootstrap?  What errors are you getting?  I would recommend building cmake,
and running its tests, because if they are not working, then VTK most likely will not work.

We used to have OSF dashboards, but the contributors stopped submitting them.
I am not surprised that it is not working.   If you have access to one of these
machines, and would like VTK/CMake to work on it, I can help you, but in return I would
request that you set up a dashboard and submit nightly.  Otherwise, it is a waste of time, since
it will be broken a few months from now with some other problem.

-Bill





--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: http://www.yeraze.com
_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers
Reply | Threaded
Open this post in threaded view
|

Re: Problem with VTK on Compaq SC45/OSF1

William A. Hoffman
I think we should take this off the VTK list, and post a summary when we have more answers.

-Bill

_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers
Reply | Threaded
Open this post in threaded view
|

Re: Problem with VTK on Compaq SC45/OSF1

Randall Hand
Ok, time for the final results :)

Finally got VTK & Cmake compiled & installed on our SC45 OSF system.  The problem was in a few different parts:
   1) The linker was linking against the wrong libcxx.so.  Unsure why it was pulling from /usr/shlib instead of the compiler directory, but that was the source of the problem.   Even after updating my LD_LIBRARY_PATH to include the correct directory as the first entry, it wouldn't work. Had to recompile the app.
   2) CMake was pulling AR & RANLIB from the wrong directory, irrespective of the PATH.  When I manually set the CMAKE_AR and CMAKE_RANLIB to the proper ones with fully qualified path, everything worked.

Hopefully I can get a dashboard up in the next few days to keep this working a bit easier.

On 2/23/06, William A. Hoffman <[hidden email]> wrote:
I think we should take this off the VTK list, and post a summary when we have more answers.

-Bill




--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: http://www.yeraze.com
_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers
Reply | Threaded
Open this post in threaded view
|

Re: Problem with VTK on Compaq SC45/OSF1

Randall Hand
I was asked to clarify that 2nd statement a bit, so here goes.

When I did all this testing, I *know* that /usr/bin was the first entry in my path, it's in my ~/.cshrc file to be so.  But when I ran cmake, it pulled from /usr/local/bin.  Now, with a test today, it's correctly getting /usr/bin .   Why is it doing this?  I haven't the foggiest.  

My guess is that a combination of systems configuration changes & Security things going on at the site the last few weeks have got things changing by the minute.  I don't think this is any fault of CMake, more a fault of this system configuration and all the wacky stuff it has setup.  The GNU tools just don't work (segfault, IOT, do nothing, it varies), and each compiler & tool is in a different directory, referenced by shell-scripted symlink wrappers. It's a mess, and not something I expect is very "standard".

On 2/27/06, Randall Hand <[hidden email]> wrote:
Ok, time for the final results :)

Finally got VTK & Cmake compiled & installed on our SC45 OSF system.  The problem was in a few different parts:
   1) The linker was linking against the wrong libcxx.so .  Unsure why it was pulling from /usr/shlib instead of the compiler directory, but that was the source of the problem.   Even after updating my LD_LIBRARY_PATH to include the correct directory as the first entry, it wouldn't work. Had to recompile the app.
   2) CMake was pulling AR & RANLIB from the wrong directory, irrespective of the PATH.  When I manually set the CMAKE_AR and CMAKE_RANLIB to the proper ones with fully qualified path, everything worked.

Hopefully I can get a dashboard up in the next few days to keep this working a bit easier.

On 2/23/06, William A. Hoffman <[hidden email]> wrote:
I think we should take this off the VTK list, and post a summary when we have more answers.

-Bill




--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: <a href="http://www.yeraze.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.yeraze.com



--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: http://www.yeraze.com
_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers