[jira] [Commented] (HAWQ-1066) Improper handling of install name for shared library on OS X

["Kyle R Dunn (JIRA)" <ji...@apache.org>]

    [ 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)