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

From: Prof Brian Ripley <>
Date: Fri, 09 Sep 2011 13:36:07 +0100 (BST)

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

>> 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:
> 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 directory).

> Thanks,
> -steve
> --
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
>  | Memorial Sloan-Kettering Cancer Center
>  | Weill Medical College of Cornell University
> Contact Info:
> ______________________________________________
> mailing list

Brian D. Ripley,        
Professor of Applied Statistics,
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________ mailing list

Received on Fri 09 Sep 2011 - 12:43:47 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 09 Sep 2011 - 14:40:28 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive