[vtkusers] VTK on AMD64 / x86_64

[Judd Taylor]

I was just trying to get started with this VTK thing a couple of days ago
and I found this thread.

This is almost correct about the file system layout on an AMD64 machine (or
any hybrid), however, 64-bit libraries should __NEVER__ be installed in a
normal lib path (this means none in /usr/local/lib, either). Doing otherwise
is a nightmare. Trust me I found out the hard way. ldconfig won't use a
64bit library that's installed in a 32 bit lib path, and you also can't mix
them (ie. link a program with both a 32bit library and a 63bit library).

The linux filesystem hierarchy docs that include the new standard can be
found here:
http://www.pathname.com/fhs/

I have no idea what microsoft is planning to do with it's 64bit libs.

So whoever is going to fix this needs to make certain that if the software
is being compiled in a 64bit mode that it will only use 64bit libraries,
(which are in corresponding */lib64 directories to the 32 bit version), and
that any output libraries created are placed in */lib64 paths as well.

I _highly_ suggest that VTK should obey these standards. Most other software
now conforms, and the ones that are still doing their own thing are really
annoying to work with (like QT, which put libs in /usr/lib64/qt-3.3/lib by
default on most systems... I'm getting really sick of that one).

Users that compile software (like Tcl/Tk, etc), need to make sure that libs
get installed to the right places. In most cases (w/ autoconf) this is real
easy: 'configure --prefix=/usr/local --libdir=/usr/local/lib64'.

Besides hardware, I'll be glad to provide any help I can with getting this
working-- I can see myself using VTK a lot in the future.

-Judd

______________________________
Judd Taylor
Computer Research Specialist
Institute for Marine Remote Sensing
University of South Florida
140 7th Ave. South
St Petersburg, FL 33701
(727) 553-1186
(727) 553-1103 (fax)
judd at marine.usf.edu

----- Original Message ----- 
Subject: [vtkusers] VTK on AMD64 / x86_64


> That's exactly right. After getting ccmake to build (i had the 32-bit
> version of ncurses, but not the 64, so it didn't build... silently)
> and had someone who had built VTK before over my shoulder, we got it
> working. I needed to explicitly set the opengl library dir.
>
> hybrid 64/32 bit systems put 32 bit libraries in /usr/lib and
> sometimes /lib. 64 bit libraries go in /usr/lib64 and sometimes
> /lib64.. and of course all user-compiled libraries go in
> /usr/local/lib, making /usr/local/lib mostly 64 bit (at least
> for me)
> X libraries work similarly: /usr/X11R6/lib64 for 64 bit libs and
> /usr/X11R6/lib for 32 bit. I've got a custom built version of XF86
> and /usr/X11R6/lib is practically empty, so anything that tries to
> use it fails.
>
> So adding /usr/X11R6/lib64 and /usr/lib64 to the default search
> for libraries should be a good solution for future users. Make
> sure to search them before searching their lib (non-64)
> counterparts.
>
> Thank you, Mathieu and Brad, your help is very much appreciated.
>
> -tom
>
> Btw, libtcl and libtk are both in /usr/local/lib; I built them
> manually and thats where it defaults. Perhaps VTK expects a name
> like 'libtk.so' - it might be important to note they are named
> 'lib<name><version>.so', as in:
>
> libtcl8.4.so
> libtk8.4.so
> and
> libtclstub8.4.so
>
> HTH..
>
>
>  <40ABCBA1.1080005 at kitware.com>Mathieu Malaterre writes:
> >tom fogal wrote:
> >> I tried rebuilding, in a different directory than the source, the
entire
> >> VTK package.
> >> I can't use 'ccmake' - it didn't build. There were no failures, it just
> >> wasn't built when I made cmake; seemed like it wasn't even configured.
> >> I chalked it up to it not being supported on 64bit platforms.
> >> 'cmake -i' works well.
> >>
> >> The new build of VTK (with VTK_USE_RENDERING=OFF) built fine and didn't
> >> require me to jump through any hoops. It had some warnings but they
> >> seemed to be the same as in the builds whose logs I have posted.
> >> 'make Experimental' passes all 48 tests.
> >> Good to know it works, but I'll need the renderer unfortunately.
> >
> >Ok, that's exactlly what I wanted, then it means that the build is
> >failing because cmake didn't find OpenGL and didn't complain...
> >
> >So now turn VTK_USE_RENDERING=ON, and fill in:
> >
> > OPENGL_gl_LIBRARY
> >
> >For some reason you have your libGL.so in a very special that is neither
> >one of them:
> >
> >           /usr/lib
> >           /usr/local/lib
> >           /opt/graphics/OpenGL/lib
> >           /usr/openwin/lib
> >           /usr/X11R6/lib
> >
> >So you'll have to edit CMakeCache.txt and fill OPENGL_gl_LIBRARY. Then
> >try to compile again.
> >
> >> I also tried building in a different directory than the source with
> >> rendering enabled. I got the same 'missing -lGL' problem. I imagine
> >> I would end up with the same TCL issue as well but I disabled TCL
> >> for this build. This build crashes in the same place as my original
> >> email mentioned.
> >
> >Could you send us the location of your libGL.so and libtk.so / libtcl.so
> >
> >Thanks
> >Mathieu
> >
> >
> >_______________________________________________
> >This is the private VTK discussion list.
> >Please keep messages on-topic. Check the FAQ at:
> <http://public.kitware.com/cgi-bin/vtkfaq>
> >Follow this link to subscribe/unsubscribe:
> >http://www.vtk.org/mailman/listinfo/vtkusers
>
>