Skip to content

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

11 messages · Valentin Kuznetsov, Dirk Eddelbuettel, Simon Urbanek

Original
Valentin Kuznetsov
# 
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.

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

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_module -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.
Dirk Eddelbuettel
# 
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
Valentin Kuznetsov
# 
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, 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.

Regards,
Valentin.
On Apr 26, 2013, at ,Apr 26, 5:54 PM, Dirk Eddelbuettel wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Apr 26, 2013, at 6:38 PM, Valentin Kuznetsov wrote:

        

            

      
      
      
    

        
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.

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Valentin Kuznetsov
    

    

      
      #
    

  


  

      
Simon,

            

      
      
      
    

        
I'll leave it up to you (or to developers) to decide. In any case it would be appropriate to document this use case and provide suitable documentation for people who may end-up with similar problem. If you need me to test any solution I'll be happy to do so.

Regards,
Valentin.

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
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
    

    

      
      #
    

  


  

      
On 26 April 2013 at 20:11, Valentin Kuznetsov wrote:

        
| Simon,
| 
| > 
| > 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
| 
| I'll leave it up to you (or to developers) to decide. In any case it would be appropriate to document this use case and provide suitable documentation for people who may end-up with similar problem. If you need me to test any solution I'll be happy to do so.

The best idea I have had so far was to replace the hardcoded /usr/bin with an
environment variable (say: RCPP_PATH) which we set to /usr/bin/ if no value
has been set by the user.  That would allow you to override it, and other to
continue to use the working setup.  

Thoughts? 

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Valentin Kuznetsov
    

    

      
      #
    

  


  

      
Hi Dirk,
environment variable is not that bad and I'm ok with such solution.
Valentin.

        
On Apr 27, 2013, at ,Apr 27, 9:52 AM, Dirk Eddelbuettel wrote:

        

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 27 April 2013 at 20:47, Valentin Kuznetsov wrote:

        
| Hi Dirk,
| environment variable is not that bad and I'm ok with such solution.

A simple snippet should do. First attempt (indented two for the email)

  # -*- mode: makefile -*-

  all:	setval
  	echo The value is ${val}

  setval:
  ifeq ($(val),)
  val="123"
  endif


which tests out fine. The default works:

  $ make -f /tmp/mypath.make          # default case
  echo The value is "123"
  The value is 123
  $

and we can also override it:

  $ val=456 make -f /tmp/mypath.make  # value set                                                                                                  
  echo The value is 456
  The value is 456
  $ 

Should be good enough.

Dirk

| Valentin.
|

        
| On Apr 27, 2013, at ,Apr 27, 9:52 AM, Dirk Eddelbuettel wrote:

        
| 
| >

        
| > On 26 April 2013 at 20:11, Valentin Kuznetsov wrote:

        
| > | Simon,
| > | 
| > | > 
| > | > 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
| > | 
| > | I'll leave it up to you (or to developers) to decide. In any case it would be appropriate to document this use case and provide suitable documentation for people who may end-up with similar problem. If you need me to test any solution I'll be happy to do so.
| > 
| > The best idea I have had so far was to replace the hardcoded /usr/bin with an
| > environment variable (say: RCPP_PATH) which we set to /usr/bin/ if no value
| > has been set by the user.  That would allow you to override it, and other to
| > continue to use the working setup.  
| > 
| > Thoughts? 
| > 
| > Dirk
| > 
| > -- 
| > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
|

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Apr 27, 2013, at 8:47 PM, Valentin Kuznetsov wrote:

        

            

      
      
      
    

        
I'd say something along the lines of 

: ${INSTALL_NAME_TOOL=/usr/bin/install_name_tool}

should be clear enough ...

Cheers,
S

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
Just to put closure to this: Thanks to a few more off-list messages with
Simon who suggested a nice a improvement on the prior setup based on using an
environment variable, plus testing by Valentin, this issue is now taken care
of in SVN.

Thanks to everybody who helped making Rcpp that little bit better.

Dirk