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