[Bioc-devel] xps build problem on veracruz2
cstrato
cstrato at aon.at
Sun Apr 23 21:15:26 CEST 2017
Dear Herve,
I have just seen that the newest build xps_1.3.3:
http://bioconductor.org/checkResults/devel/bioc-LATEST/xps/veracruz2-buildsrc.html
still results in an error.
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://root.cern.ch/build-root-old-method
>
> 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://root-forum.cern.ch/t/rootn-exe-startup-crashes-on-ubuntu-14-04-4/20825/11
>
> 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://root-forum.cern.ch/t/compilation-problem-with-os-sierra-xcode-8-root-6-06-08/22102/6
>
> 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://root.cern.ch/building-root
>>
>> 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