What I need to know in the immediate future is: does this affect the new patch
that we just put in the 1.6rc2 tarball?
http://www.open-mpi.org/community/lists/devel/2012/05/10968.php
Meaning: I want to release 1.6 in the immediate future. Is this a blocker? If
so, how fast can we get a fix?
On May 2, 2012, at 6:07 PM, Evan Clinton wrote:
> What I mean to say is that, as far as I can tell, in Open MPI's
> configure stuff there's a switch based on what it detects the host
> processor as (and this detection could be overridden by specifying the
> --host= thing); this is probably not the best way to do it.
>
> (sorry for the double-post again, dangit)
>
> On Wed, May 2, 2012 at 5:52 PM, Peter Robinson <pbrobin...@gmail.com> wrote:
>> On Wed, May 2, 2012 at 10:38 PM, Evan Clinton <evan.m.clin...@gmail.com>
>> wrote:
>>>> The Fedora guys are having trouble building the armv5tel variant (well,
>>>> they did before this patch too, but... :)
>>>> http://arm.koji.fedoraproject.org/koji/getfile?taskID=790343&name=build.log
>>>
>>> Ah, I think the problem is that the build system is not playing nicely
>>> with cross-compiles (which it looks like that's doing (specifically,
>>> in that case, compiling for armv5 on an armv7 box)). I think an
>>> immediate workaround would be to do ./configure
>>> --host=armv5tel-unknown-linux-gnueabi or similar (in addition to
>>> specifying the target -march). I think you'd need to specify the
>>> --host in a similar manner for any cross-compile of Open MPI?
>>
>> It's not cross compiling, it's native compile although it might be
>> underlying armv7 device but it's running a armv5tel userspace.
>> Ultimately for distribution compile platforms it should be paying
>> attention to what the build system is telling it to compile for not
>> the underlying device because it's built once and could be run on any
>> number of devices.
>>
>> Peter
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
