[ https://issues.apache.org/jira/browse/HAWQ-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510987#comment-15510987 ]
Kyle R Dunn commented on HAWQ-1066: ----------------------------------- Current work-around is adding: {code} if [[ "$OS_UNAME" == "Darwin" ]]; then install_name_tool -id `pwd`/usr/lib/libhdfs3.1.dylib `pwd`/usr/lib/libhdfs3.1.dylib fi {code} into a bash script that runs as a wrapper around the build task, goal is to have the official CMake files configured correctly. > Improper handling of install name for shared library on OS X > ------------------------------------------------------------ > > Key: HAWQ-1066 > URL: https://issues.apache.org/jira/browse/HAWQ-1066 > Project: Apache HAWQ > Issue Type: Bug > Components: libhdfs > Reporter: Kyle R Dunn > Assignee: Lei Chang > > Created as a carryover for [libhdfs3 Github > #40|https://github.com/Pivotal-Data-Attic/pivotalrd-libhdfs3/issues/46] on > behalf of [elfprince13|https://github.com/elfprince13]: > I am working on a project that has libhdfs3 as a submodule in our git repo. > Since we want to keep the build process contained in a single (user-owned) > directory tree, we configure with {{cmake > -DCMAKE_INSTALL_PREFIX:PATH=$(pwd)/usr}}. However, after running {{make && > make install}}, I then find the following incorrect behavior when I run > {{otool}}. > {code} > [thomas@Mithlond] libhdfs3-cmake $ otool -D usr/lib/libhdfs3.dylib > usr/lib/libhdfs3.dylib: > libhdfs3.1.dylib > {code} > Note that since the install name is incorrectly set, linking against this > copy of the library, even by absolute path, will produce a binary that can't > find libhdfs3.dylib without manually altering LD_LIBRARY_PATH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)