[Bioc-devel] xps build problem on veracruz2

cstrato cstrato at aon.at
Sun Apr 23 23:17:31 CEST 2017


Yes, I know.
I wanted only to mention that this error is hopefully corrected in 
today's update.
Christian


On 04/23/17 22:19, Hervé Pagès wrote:
> On 04/23/2017 12:15 PM, cstrato wrote:
>> Dear Herve,
>>
>> I have just seen that the newest build xps_1.3.3:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_xps_veracruz2-2Dbuildsrc.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o&s=ZEHBjBTxOazamSZVumdls85OBYuWJInbBU0MEarY2OE&e=
>>
>> still results in an error.
>
> Please understand that the build report is lagging behind your latest
> activities on the package.
>
> Today's report says:
>
>   Snapshot Date: 2017-04-22 17:18:01 -0400 (Sat, 22 Apr 2017)
>
> and your rpath fix is from this morning:
>
>   hpages at latitude:~/svn/bioconductor/Rpacks/xps$ svn log -r 129056
>   ------------------------------------------------------------------------
>   r129056 | c.stratowa | 2017-04-23 08:07:00 -0700 (Sun, 23 Apr 2017) |
> 2 lines
>
>   update to xps-1.35.4
>   - update rpath
>   ------------------------------------------------------------------------
>
> H.
>
>> This is probably due to the fact that it still requires $ROOTSYS.
>> I hope that my current upload xps_1.3.4 has eliminated this dependency
>> (see my mail below).
>>
>> Best regards,
>> Christian
>>
>>
>> On 04/23/17 17:31, cstrato wrote:
>>> Dear Herve,
>>>
>>> Since some users report problems since many years that the libs are
>>> found in '/usr/local/root/lib/root', I agree that it is a good idea
>>> to set LDFLAGS also to
>>>    LDFLAGS = ... -rpath $(shell $(ROOTCONFIG) --prefix)/lib/root
>>>
>>>
>>> I have just uploaded version xps_1.3.4 to BioC devel.
>>>
>>> In this version I have added
>>> - LDFLAGS = ... -rpath $(shell $(ROOTCONFIG) --prefix)/lib/root
>>> - Furthermore, I have removed the dependency on the variable $ROOTSYS
>>>   in the case ROOT is installed in fixed location.
>>>   (see Makefile.arch line 47 and Makefile line 115)
>>> - I have also added an INSTALL file (which I need to update).
>>>
>>>
>>> I understand that you have built ROOT using the new build system
>>> with 'cmake'. On Yosemite and earlier machines you can (and probably
>>> should) use the old build system using 'make', which is described in:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_build-2Droot-2Dold-2Dmethod&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o&s=jpz0-unZsEzxF9QEqOrMLG7y59pLxuv6K_ZqP0gUbmo&e=
>>>
>>>
>>> Interestingly, there is the statement:
>>> Using the fixed location mode, the default "--prefix" path is
>>> `/usr/local',
>>> which will result in the ROOT files to be installed in `/usr/local/bin',
>>> `/usr/local/lib/root', etc.
>>>
>>> This means probably, that you could use:
>>>     cmake -DCMAKE_INSTALL_PREFIX=/usr/local
>>> but maybe you still end up with libs in /usr/local/root/lib/root.
>>>
>>>
>>> BTW, on Sierra I have just upgraded to the new version R-3.4.0.pkg.
>>> I must realize that R-3.4.0 requires El Capitan or higher, which means
>>> that people using Yosemite or Mavericks can no longer upgrade to the
>>> newest version of R! Is this correct?
>>>
>>> Best regards,
>>> Christian
>>>
>>>
>>> P.S.:
>>> I am not sure if the following information is of interest to you, but I
>>> was looking at my old mails and I searching the ROOT forum, where users
>>> also report problems since the libraries got installed under
>>> /usr/local/root/lib/root:
>>>
>>>
>>> 1, One series of mails is from/to Dan with cc to you from 03/17/12
>>> regarding installing ROOT on openSUSE 12.1. He mentioned that the libs
>>> were stored in /usr/local/root/lib/root. My response was that he only
>>> need to change prefix to "--prefix=/usr/local". However he reported
>>> that the problem was lack of read and listing permissions on the
>>> /etc/root directory.
>>>
>>>
>>> 2, One user recently (Mar 2016) tried to install ROOT 6 on Ubuntu
>>> 14.04.4, see:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__root-2Dforum.cern.ch_t_rootn-2Dexe-2Dstartup-2Dcrashes-2Don-2Dubuntu-2D14-2D04-2D4_20825_11&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o&s=82sayza_dHZujyTaKcKBVovo-64NMD7uZbfE2W5gMu4&e=
>>>
>>>
>>> and reported, e.g. /usr/local/root/lib/root/libCore.so
>>> He then tried:
>>>
>>> cmake -DCMAKE_INSTALL_PREFIX="/usr/local"
>>> /home/johnsont/rootsrc/root-6.06.02
>>> cmake --build .
>>> sudo cmake --build . --target install
>>>
>>> It seems that now the libraries did install correctly (but there were
>>> other issues).
>>>
>>>
>>> 3, One user had compilation problems on OS Sierra (Oct 2016), see:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__root-2Dforum.cern.ch_t_compilation-2Dproblem-2Dwith-2Dos-2Dsierra-2Dxcode-2D8-2Droot-2D6-2D06-2D08_22102_6&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o&s=hrIBBK0fqAFQNmW8a8vTIHbmcNOB7IVjsclAMGCjKLY&e=
>>>
>>>
>>> There was an interesting reply:
>>>
>>> Better don't use -j4 when using cmake, just when using make.
>>>
>>> I am not sure whether this is still true, since it seems to work in your
>>> case.
>>>
>>>
>>>
>>> On 04/23/17 02:32, Hervé Pagès wrote:
>>>> On 04/22/2017 02:57 PM, cstrato wrote:
>>>>> Dear Herve,
>>>>>
>>>>> Thank you for your efforts to get xps running.
>>>>>
>>>>> I will make the changes in Makefile.arch, too, and update README and
>>>>> rename it to install.
>>>>>
>>>>> I am also surprised that the libs get installed under
>>>>> <prefix>/lib/root,
>>>>> and I will check if there is a reason for this.
>>>>>
>>>>> As far as I remember, long time ago someone had a similar problem, see
>>>>> e.g.:
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_51838_&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=lvjHdGnauUA25Q4WQU1Y7Sn74tcZrxSh529Bwgg5tG4&s=P0qNlFiUPP9UB0MiGeyiKvTPduWT0c3yp24Q7hNkWDY&e=
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Do you use the environment variable ROOTSYS?
>>>>
>>>> I gave you the full transcript of what I do for
>>>> configure/build/install. I'm following the "fix location"
>>>> installation procedure as described here:
>>>>
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_building-2Droot&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o&s=oyWYquttGiTDd8dpdy0btsLNCK9Yllv6ne2PejRx7tI&e=
>>>>
>>>>
>>>> so no ROOTSYS (the above document doesn't even mention that
>>>> variable).
>>>>
>>>> H.
>>>>
>>>>>
>>>>> Best regards,
>>>>> Christian
>>>>>
>>>>>
>>>>>
>>>>> On 04/22/17 22:36, Hervé Pagès wrote:
>>>>>> Hi Christian,
>>>>>>
>>>>>> Thanks for the update. Glad it works for you.
>>>>>>
>>>>>> One small thing is that, if CMAKE_INSTALL_PREFIX is specified
>>>>>> when configuring ROOT, the ROOT libs get installed under
>>>>>> <prefix>/lib/root, not under <prefix>/lib. I was surprised by
>>>>>> this, but that's what I got when I installed ROOT on veracruz2.
>>>>>> I configured with:
>>>>>>
>>>>>>     export CC=/usr/local/clang4/bin/clang
>>>>>>     export CXX=/usr/local/clang4/bin/clang++
>>>>>>     cmake -DCMAKE_INSTALL_PREFIX=/usr/local/root -Dgnuinstall=ON
>>>>>> -Dfortran=OFF -Dmysql=OFF -Dsqlite=OFF ../root
>>>>>>
>>>>>> Then built with:
>>>>>>
>>>>>>     cmake --build . -- -j4
>>>>>>
>>>>>> Then installed with:
>>>>>>
>>>>>>     sudo cmake --build . --target install
>>>>>>
>>>>>> And the libraries got installed under /usr/local/root/lib/root
>>>>>>
>>>>>> So when trying to install the latest xps, loading xps.so failed for
>>>>>> me because the ROOT libraries were not found. The following change
>>>>>> to Makefile.arch fixed the problem:
>>>>>>
>>>>>> $ svn diff Makefile.arch
>>>>>> Index: Makefile.arch
>>>>>> ===================================================================
>>>>>> --- Makefile.arch    (revision 129046)
>>>>>> +++ Makefile.arch    (working copy)
>>>>>> @@ -261,7 +261,7 @@
>>>>>>  CXXFLAGS      = $(OPT2) -pipe -Wall -W -Woverloaded-virtual
>>>>>>  LD            = $(MACOSXTARGET) g++
>>>>>>  #LDFLAGS       = $(OPT2)
>>>>>> -LDFLAGS       = $(OPT2) -rpath $(shell $(ROOTCONFIG) --prefix)/lib
>>>>>> +LDFLAGS       = $(OPT2) -rpath $(shell $(ROOTCONFIG) --prefix)/lib
>>>>>> -rpath $(shell $(ROOTCONFIG) --prefix)/lib/root
>>>>>>  UNDEFOPT      = dynamic_lookup
>>>>>>  # The SOFLAGS will be used to create the .dylib,
>>>>>>  # the .so will be created separately
>>>>>>
>>>>>> Also note that the rpaths specified at linking time get hardcoded in
>>>>>> xps.so:
>>>>>>
>>>>>> veracruz2:src biocbuild$ otool -l xps.so | tail -n 18
>>>>>> Load command 31
>>>>>>           cmd LC_RPATH
>>>>>>       cmdsize 32
>>>>>>          path /usr/local/root/lib (offset 12)
>>>>>> Load command 32
>>>>>>           cmd LC_RPATH
>>>>>>       cmdsize 40
>>>>>>          path /usr/local/root/lib/root (offset 12)
>>>>>> Load command 33
>>>>>>       cmd LC_FUNCTION_STARTS
>>>>>>   cmdsize 16
>>>>>>   dataoff 4141784
>>>>>>  datasize 14336
>>>>>> Load command 34
>>>>>>       cmd LC_DATA_IN_CODE
>>>>>>   cmdsize 16
>>>>>>   dataoff 4156120
>>>>>>  datasize 904
>>>>>>
>>>>>> So the end user will need to have the ROOT libraries at these
>>>>>> locations
>>>>>> too (unless s/he installs from source of course). This would need
>>>>>> to be
>>>>>> explained in xps README file (which BTW should preferably be named
>>>>>> INSTALL).
>>>>>>
>>>>>> Thanks,
>>>>>> H.
>>>>>>
>>>>>>
>>>>>> On 04/22/2017 05:15 AM, cstrato wrote:
>>>>>>> Dear Herve,
>>>>>>>
>>>>>>> I am glad to inform you that I have just uploaded version
>>>>>>> xps_1.35.3 to
>>>>>>> BioC-dev branch. I have followed your suggestion to use -rpath and
>>>>>>> have
>>>>>>> eliminated the environment variables DYLD_LIBRARY_PATH and
>>>>>>> LD_LIBRARY_PATH.
>>>>>>>
>>>>>>> I have tested the new version on both Yosemite and on Sierra with
>>>>>>> csrutil enabled! Thus I assume that it will also run on El Capitan.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Christian
>>>>>>>
>>>>>>> P.S.:
>>>>>>> Please allow me to comment on your note on [DY]LD_LIBRARY_PATH.
>>>>>>> As you know xps was uploaded to Bioc 10 years ago (with your kind
>>>>>>> help)
>>>>>>> and is available on BioC since 9 years.
>>>>>>> At that time the environment variables [DY]LD_LIBRARY_PATH were
>>>>>>> necessary, and for many years required by ROOT. Since xps did run on
>>>>>>> the
>>>>>>> Mac on all systems from Leopard till Yosemite w/o problems I had no
>>>>>>> need
>>>>>>> to change it.
>>>>>>> Furthermore, I had not heard that the use of these variables have
>>>>>>> been
>>>>>>> discouraged, just like many other developers who only now realize
>>>>>>> that
>>>>>>> they have to use rpath or simply disable csrutil (I have realized
>>>>>>> this
>>>>>>> when googling around).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 04/21/17 00:29, Hervé Pagès wrote:
>>>>>>>> Also relying on [DY]LD_LIBRARY_PATH is considered bad practice and
>>>>>>>> has been discouraged for years. xps is the only Bioconductor
>>>>>>>> package
>>>>>>>> that relies on these variables for its configure/build process.
>>>>>>>>
>>>>>>>> H.
>>>>>>>>
>>>>>>>> On 04/20/2017 03:24 PM, Dan Tenenbaum wrote:
>>>>>>>>> Disabling SIP should not be done anywhere. Every page I've read on
>>>>>>>>> this topic strongly discourages doing this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Hervé Pagès" <hpages at fredhutch.org>
>>>>>>>>>> To: "cstrato" <cstrato at aon.at>, "Dan Tenenbaum"
>>>>>>>>>> <dtenenba at fredhutch.org>
>>>>>>>>>> Cc: "bioc-devel" <bioc-devel at r-project.org>
>>>>>>>>>> Sent: Thursday, April 20, 2017 3:17:23 PM
>>>>>>>>>> Subject: Re: [Bioc-devel] xps build problem on veracruz2
>>>>>>>>>
>>>>>>>>>> On 04/20/2017 03:01 PM, cstrato wrote:
>>>>>>>>>>> Dear Herve,
>>>>>>>>>>>
>>>>>>>>>>> Doing 'csrutil disable' does indeed solve the problem, since:
>>>>>>>>>>>
>>>>>>>>>>> 1, in this way I was able to build xps on Mac OS Sierra
>>>>>>>>>>>
>>>>>>>>>>> 2, in this way I could already help one user of xps, see:
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_90056_-2390247&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg&s=GfzgU1Ibm_scFWO58Mv_ZfxKtn-FSJgkxMW1ZBYK1Vs&e=
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This means, that users of xps seem to be willing to disable
>>>>>>>>>>> csrutil.
>>>>>>>>>>
>>>>>>>>>> I'm not a statistician but I wouldn't draw conclusions from a
>>>>>>>>>> sample
>>>>>>>>>> of size 1. Mac users who cannot install xps on their machine will
>>>>>>>>>> use something else, or, if they desperately need xps, they will
>>>>>>>>>> grab a Linux box.
>>>>>>>>>>
>>>>>>>>>> Sorry but disabling SIP on our Mac builders is not an option.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However, I just realized that there may be an even greater
>>>>>>>>>>> problem,
>>>>>>>>>>> namely, which version of ROOT should a user install?
>>>>>>>>>>>
>>>>>>>>>>> People can download ROOT binaries built with XCode 7.x from:
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_content_release-2D53436&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg&s=LByiYPyOfsHnRc9oOqXOs9xMcfltktXgkTQ3sh5hKFc&e=
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> for OS X 10.10 and 10.11.
>>>>>>>>>>>
>>>>>>>>>>> Thus for El Capitan they can download the following binaries:
>>>>>>>>>>> - root_v5.34.36.macosx64-10.11-clang70.dmg
>>>>>>>>>>> - root_v5.34.36.macosx64-10.11-clang70.tar.gz
>>>>>>>>>>>
>>>>>>>>>>> Did you install one of those binaries or did you compile ROOT
>>>>>>>>>>> from
>>>>>>>>>>> source?
>>>>>>>>>>
>>>>>>>>>> As I said earlier, I compiled ROOT 5 from source on veracruz2.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> With the help of my README file people could compile ROOT from
>>>>>>>>>>> source
>>>>>>>>>>> for XCode 8.x.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However, you have mentioned that the CRAN people are using clang
>>>>>>>>>>> 4.0.0
>>>>>>>>>>> for producing the Mac binaries of R and CRAN packages and thus
>>>>>>>>>>> you
>>>>>>>>>>> are
>>>>>>>>>>> using the same on veracruz2.
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Did you compile ROOT with XCode 7 or 8 or did you use clang
>>>>>>>>>>> 4.0.0,
>>>>>>>>>>> which
>>>>>>>>>>> is not officially supported by Apple?
>>>>>>>>>>
>>>>>>>>>> With clang 4.0.0.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The question is whether xps built with this version of ROOT will
>>>>>>>>>>> work
>>>>>>>>>>> with the ROOT binaries which people can download from ROOT?
>>>>>>>>>>
>>>>>>>>>> I guess someone will need to figure this out.
>>>>>>>>>>
>>>>>>>>>> Note that if people need to compile their own ROOT anyway in
>>>>>>>>>> order to
>>>>>>>>>> be able to use the xps binary we distribute, then they should
>>>>>>>>>> also be
>>>>>>>>>> able to install xps from source. So that defeats the purpose of
>>>>>>>>>> providing a binary in the first place.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> H.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Christian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 04/20/17 20:00, Hervé Pagès wrote:
>>>>>>>>>>>> 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