[Rd] As a package author, is there a way to specify that your package is architecture (x86_64) specific?

Prof Brian Ripley ripley at stats.ox.ac.uk
Fri Sep 9 14:36:07 CEST 2011

On Thu, 8 Sep 2011, Steve Lianoglou wrote:

> Hi Simon,
> Thanks for the quick response.
> Comments in line:
> On Thu, Sep 8, 2011 at 4:11 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> On Sep 8, 2011, at 3:59 PM, Steve Lianoglou wrote:
>>> Hi,
>>> Essentially: subject line says it all.
>>> I've created a package that wraps an external c++ library (which I didn't write) that only successfully compiles on 64bit machines.
>> That doesn't sound right, it contradicts your subject line - x86_64 
>> is just one of many 64-bit architectures ...
> Ok, sorry for being imprecise. Let's see if we can figure out what it
> is (more precise details are at the bottom of the email). I see x86_64
> on every 64bit machine I touch (linux or mac), so I thought they were
> interchangeable (as names).

Not so.  That's not what Windows uses (it mainly uses x64, sometimes 
amd64 or x86-64, almost never x86_64), and although it is what Solaris 
uses, your Linux x86_64 assembler (presumably GNU) will not work 

>> My hunch is that it really is about the architecture, not x86_64 
>> but from what you describe it's not about an architecture at all - 
>> it's about the library .. (see below).
> [snip]
>>> I see hints in how to limit which architecture a package is built
>>> against in the R-ext and R-admin manuals where they seem to suggest to
>>> include a src/Makefile in order to do that ... but I'm not sure what I
>>> should put in it.
>> No, that's not the purpose.
> Well, the r-admin doc does suggest using your own Makefile in close
> proximity to targetting specific architectures several times ... eg.
> section 2.6, 6.3.1, 6.3.4.

No, it suggests there is an interaction: *if* you use your own 
src/Makefile it interacts with multiarch builds.  And so does having a 
configure file ....

> In fact, if you search that document for "src/Makefile" it's almost
> always found next to something that talks about compiling architecture
> specific builds ... I'm sure it's used for a lot more than that, but
> r-admin repeatedly suggests that this is one of its functions.
> But let's get to the good stuff.
>>> Even if it can't go on CRAN as 64-bit only, it would be great if I can
>>> put up some easy install instructions for people to d/l my source
>>> package externally and use it that way.
>> The configure script is designed to figure out things like that, so all you need to do is to add a configure script that will check whether the package can be built for that architecture or not.
> OK ... I was hoping I could avoid getting into configure/autoconf
> stuff, but at some point I'll have to bite the bullet and read up on
> it much more than I really want to, so I guess that will happen sooner
> than later.
>> In fact, it should really check whatever the C++ library does that 
>> prevents it from working elsewhere. The particularities depends on 
>> the library so you'll need to provide more info in oder to help you 
>> better ...
> It's doing some inline assembly. The problematic code is here:
> https://github.com/lianos/buckshot/blob/master/src/cas_array.h#L90
> Compiling the 32bit version of the library on my mac complains about
> the call to `cmpxchg`, specifically:
> /var/folders/C2/C2bsTekpH-qdLj5psUvjtk+++TM/-Tmp-//cc7q88qD.s:785:suffix
> or operands invalid for `cmpxchg'
> Doing surgery on the code to actually fix it is a bit above my pay
> grade right now as the last time I had to write in assembly was > 10
> years ago for an undergraduate class, so I'd just like to sidestep the
> issue.
> I'm not sure how to properly check if this call to cmpxchg can work
> inside a configure script or using autoconf. If it's relatively
> simple, I'd appreciate a hint if you've got one to spare, otherwise
> I'll just keep compiling the 64bit only version of the library until I
> can figure out how to sort it out.
> The library also compiles fine on our linux compute servers, which
> `uname -a` tells me are also of the x86_64 64bit variety. I'm not sure
> if that's helpful to know, but thought I'd just put it out there.

You try to compile the crucial fragament of code in configure: there 
are lots of examples of that in the R sources (mainly in the m4 

> Thanks,
> -steve
> -- 
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
>  | Memorial Sloan-Kettering Cancer Center
>  | Weill Medical College of Cornell University
> Contact Info: http://cbio.mskcc.org/~lianos/contact
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

More information about the R-devel mailing list