> > Can you post your VTK cmake commands to the list?
cmake -DBUILD_EXAMPLES=OFF -DBUILD_SHARED_LIBS=OFF -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=$(PWD) I guess not building it with -DCMAKE_BUILD_TYPE=Release creates all the different libraries. On Tue, Mar 8, 2016 at 10:47 AM, John Peterson <jwpeter...@gmail.com> wrote: > > > On Tue, Mar 8, 2016 at 7:40 AM, Harshad Sahasrabudhe <hsaha...@purdue.edu> > wrote: > >> -rpath has nothing to do with undefined references at link time. It's >>> for "baking in" the library path to an executable so it can be found at >>> runtime regardless of your LD_LIBRARY_PATH variable. >> >> The problem here seems to be that you are have built a version of VTK in >>> which "libvtkDICOMParser" is required by libvtkIO, something I've never >>> encountered before. >> >> >> But then how come the 0.9.4 VTK link test works and 0.9.5 doesn't? The >> only difference in the link command is that -rpath >> > > This appears to be a difference (that I wasn't aware of) between the > linker on OSX and the GNU linker on Linux: > > From "man ld" on OSX: > > -rpath path > Add path to the runpath search path list for image being created. > At runtime, dyld uses the runpath when searching for dylibs whose > load path begins with @rpath/. > > > > From "man ld" on Linux (GNU linker): > GNU ld (GNU Binutils for Ubuntu) 2.22 > > -rpath=dir > Add a directory to the runtime library search path. This is used > when linking an ELF executable with shared objects. All -rpath > arguments are concatenated and passed to the runtime linker, which > uses them to locate shared objects at runtime. *The -rpath option is* > * also used when locating shared objects which are needed by shared* > * objects explicitly included in the link; see the description of the* > * -rpath-link option.* If -rpath is not used when linking an ELF > executable, the contents of the environment variable "LD_RUN_PATH" > will be used if it is defined. > > -rpath-link=dir > When using ELF or SunOS, one shared library may require another. > This happens when an "ld -shared" link includes a shared library as > one of the input files. > > > So it appears that we are in the "one shared library may require another" > situation for your VTK build on Linux. Interestingly, we have not seen > this when we build VTK on Linux. We use the following cmake commands when > building VTK on Linux: > > cmake ../../VTK-6.3.0 \ > -DCMAKE_INSTALL_PREFIX=$PACKAGES_DIR/vtk-6.3/gcc-opt \ > -DCMAKE_BUILD_TYPE=Release \ > -DVTK_Group_Rendering=OFF \ > -DVTK_WRAP_PYTHON=ON \ > -Wno-dev > > Can you post your VTK cmake commands to the list? > > I guess I will also put the -rpath commands back in the configure test, > now that I know they are not just for finding stuff at runtime (at least > for certain linkers). > > -- > John > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
