[Bioc-devel] xps build problem on veracruz2

Hervé Pagès hpages at fredhutch.org
Thu Apr 20 20:00:28 CEST 2017 

On 04/20/2017 10:59 AM, Hervé Pagès wrote:
> Hi Christian,
>
> Disabling 'csrutil disable' might help xps on veracruz2 but that
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
oops, no double negative intended here. I meant, doing 'csrutil disable'
might help... etc

H.

> won't help your end users.
>
> I'm no expert in developing a package on Mac but other people on
> this list are. Also R-SIG-Mac might be a good place to seek help
> for this.
>
> Cheers,
> H.
>
>
> On 04/20/2017 10:53 AM, cstrato wrote:
>> Dear Herve,
>>
>> Thank you for your efforts to try to install xps. I am glad to hear that
>> you could build ROOT 5 from source.
>>
>> It's a pity that Apple does no longer allow the use of
>> DYLD_LIBRARY_PATH. This seems to break the code of a lot of people (when
>> googling around).
>>
>> I will try to change the build process and will see if I succeed.
>> However, at the moment I have a couple of questions:
>>
>>
>> 1, Is there any reason that you do not want to 'csrutil disable'?
>>
>>
>> 2, It is easy to delete the test for DYLD_LIBRARY_PATH in my
>> 'configure.in' file, however, I have also to change the 'Makefile'.
>>
>> Since you say that the problem can be solved by adding the -rpath flag
>> when linking, I assume that I have to change  the following line in my
>> 'Makefile':
>>         $(LD) -bundle $(LDFLAGS) $^ $(GLIBS) $(MYLIBS) \
>>            $(OutPutOpt) $(subst .$(DllSuf),.so,$@)
>>
>> Since I am not familiar with -rpath can you give me a hint how to change
>> it?
>>
>>
>> 3, There is a Wikipedia explanation for '-rpath', see:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Rpath&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0&s=ge_d4eBoKDAggNWVQUzMVPAJy250VlZuPTXcPyr20HM&e=
>>
>>
>> Interestingly, there is the following line:
>>
>> 'Instead of specifying the -rpath to the linker, the environment
>> variable LD_RUN_PATH can be set to the same effect.'
>>
>> Do you think that using LD_RUN_PATH would solve the problem?
>> If yes, then how?
>>
>>
>> 4, Googling for the DYLD_LIBRARY_PATH problem I have also found the
>> following discussion:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__forums.macrumors.com_threads_is-2Dit-2Dok-2Dto-2Duse-2Ddyld-5Flibrary-5Fpath-2Don-2Dmac-2Dos-2Dx-2Dand-2Dwhat-25C2-2592s-2Dthe-2Ddynamic-2Dlibrary-2Dsearch.956258_&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0&s=yhLXARIG_RS1LNegc7tbjO1bayLOp7zy5-rzbtjCHIk&e=
>>
>>
>> There, one answer mentioned:
>> 'Also, rpath is a good idea. Also see install_name_tool, which can
>> change the load paths of libraries.'
>>
>> Doing a search for 'install_name_tool' I found:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_2985315_using-2Dinstall-2Dname-2Dtool-2Dwhats-2Dgoing-2Dwrong&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0&s=r5LiHlxkGAeJAcciwteD2XD6ffNtWLiknvcIj9EJL8E&e=
>>
>>
>> There, one answer mentioned (see also $man install_name_tool):
>> 'Having experimented more: install_name_tool -id newname file will do
>> the trick.'
>>
>> See also:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__qin.laya.com_tech-5Fcoding-5Fhelp_dylib-5Flinking.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0&s=FL17xv1uuzR6UF59mgJstMQ-1seE1UeKDQVVXQgXnUo&e=
>>
>>
>>
>> Do you think that either using the environment variable LD_RUN_PATH or
>> using 'install_name_tool' could solve the problem without having to use
>> '-rpath'?
>>
>>
>> Thank you in advance.
>> Best regards,
>> Christian
>>
>>
>>
>> On 04/19/17 22:51, Hervé Pagès wrote:
>>> Hi Christian,
>>>
>>> So I installed ROOT 5 from source on veracruz2. It's in
>>> /usr/local/root.
>>>
>>> However, Apple's SIP (System Integrity Protection, new and
>>> enabled by default on El Capitan) is getting in the way when
>>> trying to install xps. That's because xps configure and build
>>> process relies on DYLD_LIBRARY_PATH. Problem is that this
>>> environment variable (and any other variables that control
>>> dynamic loading) is not inherited by child processes when SIP
>>> is on:
>>>
>>> veracruz2:~ biocbuild$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!';
>>> else echo 'nope!'; fi
>>> yep!
>>>
>>> veracruz2:~ biocbuild$ sh
>>> sh-3.2$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!'; else echo
>>> 'nope!'; fi
>>> nope!
>>>
>>> That breaks xps configure script:
>>>
>>> veracruz2:~ biocbuild$ export LD_LIBRARY_PATH=$DYLD_LIBRARY_PATH
>>>
>>> veracruz2:~ biocbuild$ echo $LD_LIBRARY_PATH
>>> /usr/local/mysql/lib:/usr/local/root/lib/root:/ImageMagick-7.0.5/lib:/usr/local/ensembl-vep/htslib
>>>
>>>
>>>
>>>
>>> veracruz2:~ biocbuild$ R CMD INSTALL xps
>>> * installing to library
>>> ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’
>>> * installing *source* package ‘xps’ ...
>>> checking for gcc... clang
>>> checking for C compiler default output file name... a.out
>>> checking whether the C compiler works... yes
>>> checking whether we are cross compiling... no
>>> checking for suffix of executables...
>>> checking for suffix of object files... o
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether clang accepts -g... yes
>>> checking for clang option to accept ANSI C... none needed
>>> checking how to run the C preprocessor... clang -E
>>> checking for gcc... (cached) clang
>>> checking whether we are using the GNU C compiler... (cached) yes
>>> checking whether clang accepts -g... (cached) yes
>>> checking for clang option to accept ANSI C... (cached) none needed
>>> found ROOT version 5.34/36 in directory /usr/local/root
>>>
>>> xps configuration error:
>>>
>>>    You must set the shell variable LD_LIBRARY_PATH to the
>>>    directory where ROOT resides and re-run R CMD INSTALL
>>>    e.g., (using Bourne shell syntax):
>>>
>>>       export "LD_LIBRARY_PATH=$ROOTSYS/lib:$LD_LIBRARY_PATH"
>>>       R CMD INSTALL xps
>>>
>>>    Please consult the README file for more information
>>>
>>> ERROR: configuration failed for package ‘xps’
>>> * removing
>>> ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/xps’
>>> * restoring previous
>>> ‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library/xps’
>>>
>>> That also breaks the dynlib mechanism because, after I managed to
>>> produce xps.so, it turns out that this shared object is linked to
>>> the ROOT libraries via the @rpath mechanism:
>>>
>>> veracruz2:src biocbuild$ otool -L xps.so
>>> xps.so:
>>>     xps.so (compatibility version 0.0.0, current version 0.0.0)
>>>     @rpath/libGui.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libCore.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libCint.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libRIO.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libNet.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libHist.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libGraf.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libGraf3d.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libGpad.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libTree.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libRint.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libPostscript.so (compatibility version 0.0.0, current
>>> version 0.0.0)
>>>     @rpath/libMatrix.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libPhysics.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libMathCore.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libThread.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>>> version 1226.10.1)
>>>     @rpath/libGed.so (compatibility version 0.0.0, current version
>>> 0.0.0)
>>>     @rpath/libTreePlayer.so (compatibility version 0.0.0, current
>>> version 0.0.0)
>>>     @rpath/libTreeViewer.so (compatibility version 0.0.0, current
>>> version 0.0.0)
>>>     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>>> version 120.1.0)
>>>
>>> so it can't be loaded in R:
>>>
>>>> dyn.load("xps.so")
>>> Error in dyn.load("xps.so") :
>>>   unable to load shared object
>>> '/Users/biocbuild/bbs-3.5-bioc/xps/src/xps.so':
>>>   dlopen(/Users/biocbuild/bbs-3.5-bioc/xps/src/xps.so, 6): Library not
>>> loaded: @rpath/libGui.so
>>>   Referenced from: /Users/biocbuild/bbs-3.5-bioc/xps/src/xps.so
>>>   Reason: image not found
>>>
>>> because R has no access to DYLD_LIBRARY_PATH:
>>>
>>>> Sys.getenv("DYLD_LIBRARY_PATH")
>>> [1] ""
>>>
>>> This can be addressed by adding the following flag when linking:
>>>
>>>   -rpath $(shell $(ROOTCONFIG) --prefix)/lib
>>>
>>> Do you think you can revisit xps configure and build process? Make sure
>>> you test it on a machine where SIP is enabled.
>>>
>>> Thanks,
>>> H.
>>>
>>>
>>
>>>>>  snip >>>
>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 03/23/17 17:47, Hervé Pagès wrote:
>>>>>>>>>>>>>> Hi Christian,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The CRAN folks are currently experimenting with clang 4.0.0
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> producing the Mac binaries of R and CRAN packages so we are
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> the same on veracruz2. This is a version of clang that is
>>>>>>>>>>>>>> ahead of
>>>>>>>>>>>>>> what's in XCode 8.x or XCode 7.x. So I guess that means we'll
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> to compile ROOT from source on veracruz2.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BTW any reason not to make xps work with ROOT 6?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/23/2017 07:28 AM, cstrato wrote:
>>>>>>>>>>>>>>> Dear Valerie,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have seen that you have set up a new Mac server,
>>>>>>>>>>>>>>> veracruz2,
>>>>>>>>>>>>>>> running El
>>>>>>>>>>>>>>> Capitan.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Although the development version of xps does even run on
>>>>>>>>>>>>>>> Mac OS
>>>>>>>>>>>>>>> Sierra,
>>>>>>>>>>>>>>> one issue still remains the same:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You need to install the latest ROOT version 5, since xps
>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>> with ROOT 6!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So you need to install on veracruz2 the same root version
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> installed on toluca2 running Maverics, i.e.
>>>>>>>>>>>>>>> root_v5.34.36.macosx64-10.11-clang70.dmg
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, if you have installed on El Capitan XCode 8.x
>>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>>> XCode
>>>>>>>>>>>>>>> 7.x, then you need to compile ROOT from source, i.e.:
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_download_root-5Fv5.34.36.source.tar.gz&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o&s=Lz7YkqZ3XwjRsYIXVTbSvbDvTM-jTyoWvoVSa1PdBDw&e=
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The README file of xps does explain how to compile ROOT for
>>>>>>>>>>>>>>> Sierra. This
>>>>>>>>>>>>>>> should also be valid for El Capitan running XCode 8.x.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you in advance.
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Christian
>>>>>>>>>>>>>>> _._._._._._._._._._._._._._._._._._
>>>>>>>>>>>>>>> C.h.r.i.s.t.i.a.n   S.t.r.a.t.o.w.a
>>>>>>>>>>>>>>> V.i.e.n.n.a           A.u.s.t.r.i.a
>>>>>>>>>>>>>>> e.m.a.i.l:        cstrato at aon.at
>>>>>>>>>>>>>>> _._._._._._._._._._._._._._._._._._
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o&s=0bNMm-aoHuwWs9yBRjyGHTxT0y3UceNADHgMjtosTWU&e=
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Hervé Pagès
>>>>>>>>>>>>
>>>>>>>>>>>> Program in Computational Biology
>>>>>>>>>>>> Division of Public Health Sciences
>>>>>>>>>>>> Fred Hutchinson Cancer Research Center
>>>>>>>>>>>> 1100 Fairview Ave. N, M1-B514
>>>>>>>>>>>> P.O. Box 19024
>>>>>>>>>>>> Seattle, WA 98109-1024
>>>>>>>>>>>>
>>>>>>>>>>>> E-mail: hpages at fredhutch.org
>>>>>>>>>>>> Phone:  (206) 667-5791
>>>>>>>>>>>> Fax:    (206) 667-1319
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Bioc-devel at r-project.org mailing list
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIF-g&c=eRAMFD45gAfqt84VtBcfhQ&r=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo&m=WB1ofcLb-W4SN6VNAgoSRdgRXQRPaelptAH2g0Ur7q8&s=IDfsJGqV_D7hzqLryd27eoZNIuiAIfSNATUnxMy61oo&e=
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

More information about the Bioc-devel mailing list