[Rcpp-devel] Remove hard-coded path to /usr/bin in Makevars

Simon Urbanek simon.urbanek at r-project.org
Sat Apr 27 01:12:43 CEST 2013 

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. 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.


> 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.

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

More information about the Rcpp-devel mailing list