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 <[email protected]>
>> To: [email protected]
>> Cc: [email protected], rcpp-devel
>> <[email protected]>
>> 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, [email protected] 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@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@max:~$ test -e install && echo "Found" # yet 'test -e'
>> fails
>> edd@max:~$ test -e /usr/bin/install && echo "Found" # only full
>> path works
>> Found
>> edd@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 | [email protected] | http://dirk.eddelbuettel.com
>> _______________________________________________
>> Rcpp-devel mailing list
>> [email protected]
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>
>> --
>> Dirk Eddelbuettel | [email protected] | http://dirk.eddelbuettel.com
>
>
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
