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

[Simon Urbanek]

Steve,

On Sep 9, 2011, at 8:36 AM, Prof Brian Ripley wrote:

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

Moreover not all 64-bit machines are x86_64/amd64 - there is ppc64, Sparc, MIPS64, IA64, ... which was my point about this having to do with a very particular machine type (and my suspicion involving asm was correct ;)) and not 64-bit architectures in general.


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


It's irrelevant, though, because you can build both i386 and x8_64 binaries on a x86_64 system, so it won't tell you which architecture is being built. Also some machines (e.g. older Mac OS X) will run i386 kernel while the rest of the OS runs fully in x86_64 so you can't even discard the possibility based on uname (which returns i386 in that case even though R can run in x86_64 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).
> 


Yes, that is the right thing to do. It's only a few lines of configure.in if you want to use autoconf, but if you don't, it's still fairly easy in pure shell code, just a bit more legwork.

Cheers,
Simon