[Rcpp-devel] Remove hard-coded path to /usr/bin in Makevars
Dirk Eddelbuettel
edd at debian.org
Sat Apr 27 02:12:44 CEST 2013
On 26 April 2013 at 19:12, Simon Urbanek wrote:
| On Apr 26, 2013, at 6:38 PM, Valentin Kuznetsov wrote:
|
| > Dirk,
| >
| > having hard-coded path is usually lead to trouble regardless of the OS. Users may have dedicated system with specific compiler/tools in different location. What you need is auto-detection of required components. Since /usr/bin is always in a PATH you don't really need it either. But as I described the different location of gcc/g++ requires appropriate linker and if you enforce in your setup specific linker it leads to the problem. My OS X setup is not unique,
|
| It absolutely is. It's not even supported by us - so you're entirely on your own.
100% agreed.
I have been with Linux long enough to remember the very old days before more
standardization of tools and toolchains, and what you (ie Valentin) have here
is old school non-standard use.
| That doesn't mean that a better way of detecting install_name_tool would be useful, but your argument is entirely moot IMHO.
|
| I suppose it would be possible to replace it simply with
| @-install_name_tool -id $(R_PACKAGE_DIR)/lib$(R_ARCH)/$(USERLIB) $(USERLIB) 2>/dev/null
|
| such that install_name_tool would be run unconditionally -- the drawback is that a failure like in your case would not be reported. If you have a better solution that is cross-platform and uses only the shell, please share it with us.
Right.
And after a number of iterations, and gentle prodding by (mostly) Simon (and
others) we arrived at a system where Rcpp installs _fine_ on standard systems
covering multiple OSs and distros -- without requiring configure.
And I would much prefer not to have to go back to configure just because of
one odd OS X setup with gcc and open mp (or whatever motivated you here).
| > many Linux systems may have compiler (or even multiple version of compiler) in different location (I work in High-Energy community and we build our tools ourselves, including compiler and the rest of the OS). What matter is consistency and your setup is not consistent with user environment.
| >
| > If you don't want to introduce robust configure tool chain you can easily create bash script to test location of required tools. If it is required I can write one.
| >
|
| Rcpp doesn't have a configure script because that prevents packages from being build as multi-lib, so that's not a good option.
Exactly.
So we would _much_ prefer not to loose the generality we currently have just
to accomodate your specificity. That said, there may be a better
solution. It just has not been proposed yet.
Dirk
| Cheers,
| Simon
|
|
|
| > Regards,
| > Valentin.
| >
| > On Apr 26, 2013, at ,Apr 26, 5:54 PM, Dirk Eddelbuettel wrote:
| >
| >>
| >> Hi Valentin,
| >>
| >> Thanks for subscribing.
| >>
| >> On 26 April 2013 at 17:08, Valentin Kuznetsov wrote:
| >> | Hi,
| >> | this is re-post from
| >> | https://r-forge.r-project.org/tracker/?func=detail&atid=637&aid=2743&group_id=155
| >> | as been advised by Dirk.
| >>
| >> Now that you are here, let me repost what I wrote earlier. I'll intend it all
| >> by two spaces.
| >>
| >> I still think that what you suggested is not all that appealing as a general
| >> solution; you have a very particular local setup and maybe you will just have
| >> to diver /usr/bin/install_name_tool. I don't want to break the general OS X
| >> setup for which this is part (and was added/suggested by Simon a while back).
| >>
| >> Dirk
| >>
| >> Quoted earlier message below
| >>
| >> From: Dirk Eddelbuettel <edd at debian.org>
| >> To: rcpp-bugs at r-forge.r-project.org
| >> Cc: simon.urbanek at r-project.org, rcpp-devel <rcpp-devel at r-forge.wu-wien.ac.at>
| >> Subject: Re: [Rcpp-devel] [rcpp-Bugs][2743] Remove hard-coded path to
| >> /usr/bin in Makevars
| >> Date: Fri, 26 Apr 2013 14:21:56 -0500
| >>
| >>
| >> On 26 April 2013 at 20:56, rcpp-bugs at r-forge.r-project.org wrote:
| >> | Bugs item #2743, was opened at 2013-04-26 18:56 by Valentin Kuznetsov
| >> | You can respond by visiting:
| >> | https://r-forge.r-project.org/tracker/?func=detail&atid=637&aid=2743&group_id=155
| >> |
| >> | Status: Open
| >> | Priority: 3
| >> | Submitted By: Valentin Kuznetsov (vkuznet)
| >> | Assigned to: Nobody (None)
| >> | Summary: Remove hard-coded path to /usr/bin in Makevars
| >> | Hardware: Macintosh
| >> | Product: None
| >> | Operating System: MacOS X
| >> | Component: None
| >> | Version: None
| >> | Severity: None
| >> | Resolution: None
| >> | URL:
| >> |
| >> |
| >> | Initial Comment:
| >> | I was unable to build Rcpp due to the fact that on my system I use
| >> | another compiler (it is installed from MacPorts in /opt/local/bin
| >> | area). The Rcpp/src/Makevars uses hard-coded path to /usr/bin/install_nam
| >> | e_tool. This cause the linker to pick-up wrong install_name_tool which in my case should come from location of my compiler (i.e. /opt/local/bin). The error I got was the following:
| >> |
| >>
| >> It would appear that you are referring to the last line of this section:
| >>
| >> $(USERLIB): $(OBJECTS)
| >> $(SHLIB_CXXLD) -o $(USERLIB) $(OBJECTS) $(SHLIB_CXXLDFLAGS) $(ALL_LIBS)
| >> @if test -e "/usr/bin/install_name_tool"; then /usr/bin/install_name_tool -id $(R_PACKAGE_DIR)/lib$(R_ARCH)/$(USERLIB) $(USERLIB); fi
| >>
| >> That line, if memory serves, suggested and provided by Simon for the OS X
| >> case. It acts as both a test for OS X (as no other OS has
| >> /usr/bin/install_name_tool) as well as a use of the tool.
| >>
| >> What you suggest (ie remove the leading /usr/bin/) does not seem to
| >> work. Witness this:
| >>
| >> edd at max:~$ ls -l /usr/bin/install # I know I have thos
| >> -rwxr-xr-x 1 root root 113864 Nov 19 16:20 /usr/bin/install
| >> edd at max:~$ test -e install && echo "Found" # yet 'test -e' fails
| >> edd at max:~$ test -e /usr/bin/install && echo "Found" # only full path works
| >> Found
| >> edd at max:~$
| >>
| >> With that I think your bug report is way too local. I am sorry that your
| >> particular case is not covered by our installation, but I have not intention
| >> of breaking lots of working systems only to accomodate you.
| >>
| >> There may be other ways, and I am open to suggestions. Maybe Simon can help
| >> once more.
| >>
| >> One idea would be
| >>
| >> @if test -e "/usr/bin/install_name_tool"; then install_name_tool -id $(R_PACKAGE_DIR)/lib$(R_ARCH)/$(USERLIB) $(USERLIB); fi
| >>
| >> which still has the explicit test with a path, but then calls without a
| >> path. Or is that too fragile?
| >>
| >> Any help from OS X users appreciated
| >>
| >> Dirk
| >>
| >> |
| >> | R CMD INSTALL /Users/vk/Work/Languages/R/Rcpp_0.10.3.tar.gz
| >> |
| >> | Loading required package: utils
| >> |
| >> | * installing to library ‘/Users/vk/Library/R/3.0/library’
| >> |
| >> | * installing *source* package ‘Rcpp’ ...
| >> |
| >> | ** package ‘Rcpp’ successfully unpacked and MD5 sums checked
| >> |
| >> | ** libs
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c Date.cpp -o Date.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c Module.cpp -o Module.o
| >> |
| >> | /opt/local/bin/gcc-mp-4.7 -std=gnu99
| >> -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG
| >> -I../inst/include/ -I/opt/local/include -fPIC -O2
| >> -DOS_OBJECT_USE_OBJC=0 -m64 -c Rcpp_init.c -o Rcpp_init.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c Timer.cpp -o Timer.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c api.cpp -o api.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c attributes.cpp -o attributes.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c barrier.cpp -o barrier.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -I/opt/local/Library/Frameworks/R.framework/Resources/include -DNDEBUG -I../inst/include/ -I/opt/local/include -fPIC -O2 -m64 -c exceptions.cpp -o exceptions.o
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -dynamiclib -Wl,-headerpad_max_install_names
| >> -undefined dynamic_lookup -single_module -multiply_defined suppress
| >> -L/opt/local/lib -o Rcpp.so Date.o Module.o Rcpp_init.o Timer.o api .o attributes.o barrier.o exceptions.o -F/opt/local/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
| >> |
| >> | /opt/local/bin/g++-mp-4.7 -o libRcpp.dylib Date.o Module.o Rcpp_init.o
| >> Timer.o api.o attributes.o barrier.o exceptions.o -dynamiclib
| >> -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_modul
| >> e -multiply_defined suppress -F/opt/local/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
| >> |
| >> | /usr/bin/install_name_tool: object: libRcpp.dylib malformed object (unknown load command 15)
| >> |
| >> | make: *** [libRcpp] Error 1
| >> |
| >> | ERROR: compilation failed for package ‘Rcpp’
| >> |
| >> |
| >> |
| >> | To fix the problem I untar the source code, modified Rcpp/src/Makevars,
| >> replaced the path to install_name_tool, tar the package again and
| >> manually install it. Please review your test in Makevars and remove hard-coded path to install_name_tool. It should be picked up from the environment.
| >> |
| >> | Thanks,
| >> |
| >> | Valentin.
| >> |
| >> | ----------------------------------------------------------------------
| >> |
| >> | You can respond by visiting:
| >> | https://r-forge.r-project.org/tracker/?func=detail&atid=637&aid=2743&group_id=155
| >>
| >> --
| >> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
| >> _______________________________________________
| >> Rcpp-devel mailing list
| >> Rcpp-devel at lists.r-forge.r-project.org
| >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| >>
| >> --
| >> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
| >
| >
|
--
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
More information about the Rcpp-devel
mailing list