vel/2014/11/16294.php
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: http://www.open-
>> mpi.org/community/lists/devel/2014/11/16295.php
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/11/16296.php
-
Prof. Dr.-Ing. Rainer Keller
Hochschule für Technik Stuttgart
Fakultät für Vermessung, Informatik und Mathematik
Schellingstr. 24, Raum 2/449
70174 Stuttgart
T.: +49 (0)711 8926-2812
F.: +49 (0)711 8926-2553
gt;>> REMOVE memoryhole:Kyle Wheeler **NO COMMITS IN LAST
>>> YEAR**
>>> REMOVE tdd: Terry Dontje
>>>
>>> The following accounts timed out due to lack of response, and have been
>>> deleted. I suspect that at least some of these will realize
Hi Tim,
in fact I was trying the OR-alternative -- however, it's only a win on older
AMD Opterons (16 cycles vs. 20), but cannot beat the __builtin_clz alternative
on Intel.
Best regards,
Rainer
On Wednesday 12 October 2011 11:26:52 Tim Mattox wrote:
> All,
> If you wanted to speedup these ro
reak;
> +*mask = parse_dots("255.255.255.0");
> +break;
1 issue: buglet in
case 24 -> break then parse_dots, then break again ,-]
Well, the other issue Tim already mentioned. I would vote for making the code
readable, aka short.
Thanks!
Raine
s true
> multi-device/multi-rail algorithms. The BML (BTL multiplexing layer) is a
> thin management later that marshals all the BTLs in the process together
> -- it's mainly array handling, etc. The ob1 PML is the one that decides
> multi-rail/device splitting, etc. The INRIA f
tion declaration: rindex
Hmm, fixed in r23671
> "../../../../openmpi-1.5rc5/orte/mca/plm/base/plm_base_rsh_support.c",
> line 565: warning: improper pointer/integer combination: op "="
fixed by the above as well.
Best regards,
Rainer
--
---
solution to this is
> simply to add a "noreturn_funcptr" probe to
> opal/config/opal_check_attributes.m4, analogous to the format_funcptr
> probe and then define and use a __opal_attribute_noreturn_funcptr__ as
> appropriate.
>
> -Paul
--
-
.1 (Apple Computer, Inc. build
> 5341)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> -Paul
--
---
: 723663
f_ffree: 723661
f_fsid : TMPFS (0x0)
f_namelen : 255
(the program detects most Filesystems according to their known magic).
Regards,
Rainer
--
----
Dr.-Ing. Rainer Keller http://www.hlrs.de/people/keller
HLRS
(e.g. collisions on the network) and should
> probably posted to a new thread.
>
> Thank you guys for your help.
>
> oli
>
--
----
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge
ional information should I provide for you?
>
> Thanks for your time
>
> oli
>
--
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
gt; > > update if you need to, etc.
> > >
> > > --
> > > Jeff Squyres
> > > jsquy...@cisco.com
> > > For corporate legal information go to:
> > > http://www.cisco.com/web/about/doing_business/legal/cri/
> > >
> > >
> >
to opal...barring arguments to the contrary.
>
> Ralph
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
---
a ticket that is not a matching CMR, etc.),
the commit will abort *WITHOUT WRITING TO THE SVN REPOSITORY* and show you a
brief error message indicating what you did wrong. You can just fix what you
did wrong and then re-commit.
With best regards,
Jeff and Rainer
--
---
Tuesday.
Regardless of whether we re-branch or not, we'd like to ask all to ramp up
v1.5 MTT-testing, possibly even by adding other test applications.
With best regards,
Jeff and Rainer
--
--------
Rainer Keller, PhD
sp. with
regard to optional ddt) are too low.
Several features of MPI (MPI-2 are not well represented in MTT).
--
----
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241
y requested for such intrusive changes, an RFC letting people
know in advance would have been nice ;-)
Thank You very much.
With best regards,
Rainer
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge Nati
n the not-distant future.
>
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
or
shell$ mpirun --mca pml cm ...
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
sufficient in that case as it is the only pml that */
- /* will be considered */
-*priority = 1;
+*priority = 30;
}
/* modulo updating the comment */
Best regards,
Rainer
--
Rainer Keller, PhD
ot looked
> any farther than this -- the new comment caught my eye)
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
; >> NetPipe-3.7.1 on smoky using BTL/sm, giving 1.6usecs on this
> >> platform).
> >
> > 1.6us sounds like pretty high sm latency... Is this a slow platform?
> >
> > --
> > Jeff Squyres
> > Cisco Systems
--
-
make sure not to feed up
> with wrong parameters, yet since it leaves to dangerous memory
> allocation/usage, doesn't it serve as a security threat ?
>
> Pardon me if I misunderstood things since I'm still learning and testing
> with these codes...
>
> Thanks,
> Prasad.
--
s -n 1000) however have shown problems (that have
hinted to bugs) when switching from eager protocol... These have been fixed in
ompi.
--
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab
it will eventually be fixed
>
> I don't know whether anyone is using either of these comments to
> justify anything.
>
> Iain
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
me, were Fortran INTEGER does not match any
** of the C-integral types.
With best regards,
Rainer
--
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
ht
* now is beyond a reasonable scope - this comment is
* placed here to explain the abstraction break and
* indicate that it will eventually be fixed
*/
On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote:
> On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote:
> > > R
r breaking the
> > abstraction barrier no longer exists, so whatever we do here is free
> > to reflect that change in requirement.
> >
> > I would personally like to see OPAL retain its original objective and
> > avoid having Fortran knowledge down there.
> >
er sign that the push of the DDT to OPAL
> > is a
> > bad idea. That's been my opinion from the start, so I'm biased.
> > But OPAL
> > was intended to be single process systems portability, not MPI crud.
> >
> > Brian
> >
> > On Mon, 1 J
Hmm, OK, I see.
However, I do see potentially a problem with work getting ddt on the OPAL
layer when we do have a fortran compiler with different alignment requirements
for the same-sized basic types...
As far as I understand the OPAL layer to abstract away from underlying system
portability, l
9: WANT_PERUSE does not appear in AM_CONDITIONAL
>
>
> Ralph
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
X_ERROR_STRING
> > + integer MPI_MAX_OBJECT_NAME
> > + integer MPI_MAX_INFO_KEY
> > + integer MPI_MAX_INFO_VAL
> > + integer MPI_MAX_PORT_NAME
> > + integer MPI_MAX_DATAREP_STRING
> > + parameter (MPI_MAX_PROCESSOR_NAME=@OPAL_MAX_PRO
RING([--with-openib-control-hdr-padding],
> - [Add padding bytes to the openib control header])])
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab
gt; >> indeed good reasons they might not. For example, at LANL, we
> >> frequently compiled OMPI with GCC, then fixed up the wrapper compilers
> >> to use Icc or whatever, to work around optimizer bugs. This is
> >> functionality I don't think should be
GASnet file
portable_platform.h which offers the CPP magic to figure out compilers and
esp. compiler-versions.
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (
w the "little macro thingy" ;-)
I failed to find it...
However, in other parts of the code base, we just use "%lu" and cast to
unsigned long...
Thoughts?
Thanks,
Rainer
--
--------
Rainer Keller, PhD
Rainer
--
----
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
t; >
> > --
> > Jeff Squyres
> > Cisco Systems
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
---
ntime/params.h"
> +#include "ompi/communicator/communicator.h"
> +#include "ompi/errhandler/errhandler.h"
>
> to lots of ompi/mpi/c/*.c files. I don't quite grok from your commit
> comment why that was a good thing...?
>
> Thanks!
--
---
ignal’ undeclared (first
> use in this function)
> make[2]: *** [snapc_full_app.lo] Error 1
> make[2]: Leaving directory `/usr/local/src/ompi-trunk/orte/mca/snapc/full'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/local/src/ompi-trunk/orte'
> make: *** [all-recursive] Error 1
--
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
st a "heads up". Please let us know if there are any concerns
> with that plan.
>
> Ralph & Jeff
> aka. Mutt & Jeff (for those of you old enough to remember that comic strip)
>
> No waitthat should be Ralph & the Mutt!
--
-
---
Dr.-Ing. Rainer Keller http://www.hlrs.de/people/keller
HLRS Tel: ++49 (0)711-685 6 5858
Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832
70550 Stuttgartemail: kel...@hlrs.de
Germany AIM/Skype:rusraink
d; /**
> > instantiated in orte/runtime/orte_init.c */
> >
> > #define ORTE_PROC_MY_NAME (&orte_process_info.my_name)
> >
> > ___
> > svn mailing list
> > s...@open-mpi.org
> > http:/
forgotten about it by then :-
> ( ...what were we talking about again?)
>
> On Mar 19, 2009, at 5:12 PM, Rainer Keller wrote:
> > Hi Ralph,
> >
> > On Wednesday 18 March 2009 09:00:36 am Ralph Castain wrote:
> > > Could we hold off on this until after 1.3.2 is out
headers are required -- as unnecessary
headers were removed in lower-level headers).
Thanks,
Rainer
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2
With best regards,
Rainer
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
check_unnecessary_h
s you've identified in the RFC) can be solved, the impact to code
> > base
> > maintainability is reasonable, and the impact to performance is
> > negligable, I'll gladly remove my objection to this RFC.
> >
> > Further, before any work on this branch is brou
renames),
such as a opal_keyval-change, we will continue to write RFCs.
--
--------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email:
And reverted both r20739 and r20740.
With best regards,
Rainer
On Thursday 05 March 2009 04:25:18 pm Ralph Castain wrote:
> This is what we expressly said NOT to do in Louisville
--
----
Rainer Keller,
tch was to ease the handling within redefinition files and scripts that
we need to do to handle the transition.
Of course, I can revert the change.
With best regards,
Rainer
--
--------
Rainer Keller, PhD Tel: +1 (8
The code has probably never been build for
> FORTRAN with 64-bit integers.
Hmm, not by me after r8254, when the same applied to sizeof(logical)!=
sizeof(int)... Then I tested these cases.
Thanks again.
With best regards,
Rainer Keller
--
--
do create Fortran handles in some
> >> performance-critical sections of code (e.g., MPI_ISEND), so
> >> eliminating an extra test is not a bad thing to do.
> >>
> >> On Feb 1, 2009, at 11:40 AM, Broto, Laurent G. wrote:
> >>> Hi folks,
> >&
ainer
--
Rainer Keller, PhD Tel: (865) 241-6293
Oak Ridge National Lab Fax: (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
lts.
Any comments are welcome.
CU,
Rainer
--
--------
Rainer Keller, PhD Tel: (865) 241-6293
Oak Ridge National Lab Fax: (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN
, I appreciate your
> > and others' efforts to expand the number of platforms
> > we can run on. Great work!
> > --
> > Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
> > tmat...@gmail.com || timat...@open-mpi.org
> >I'm a bright... http://ww
ully that made sense...
Yes, breaking into chunks (such as the CMakeLists.txt + .windows files, the
CCP component and finally the files that touch other files) is a good way
forward.
CU,
Rainer
--
Dipl.-Inf. Rainer Keller http:
anner. **
> >>
> >>
> >>*
> >>
> >>
> >> ___
> >>devel mailing list
> >>d
he req_state in ompi_request is only used for persistent requests?
Could You please look into #1349?
Question is, whether request->req_status always contains the correct status
(for inactive persistent request)
Thanks,
Rainer
--
----
Dipl.-
= req->req_status.MPI_SOURCE;
> >>> +status->MPI_ERROR = req->req_status.MPI_ERROR;
> >>> status->_count = req->req_status._count;
> >>> status->_cancelled = req->req_status._cancelled;
> >>> }
> >&
gt;> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
---
gt; valgrind
> >>>> support was requested
> >>>> configure: error: *** Cannot continue
> >>>>
> >>>>
> >>>> Could somebody please fix this? I thought we had decided many moons
> >>>> ago that
> >>>> we wo
uiring You to get rid of the attribute?
The attribute should help find errors in the callers to
orte_errmgr_base_abort...
Maybe the help on
https://svn.open-mpi.org/trac/ompi/wiki/CompilerAttributes
could be improved?
Thanks,
Rainer
--
-----
ow of any issues, errors, suggestions, omissions,
> heartburn, etc.
>
> Thanks,
> --Brad
>
> Brad Benton
> IBM
--
----
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
HLRS Tel: ++49
es,
> > ii) Or the implementation of the MPI_Type_size function has to be
> > modified to
> > return the value of eg. true_ub which contains the correct value
> > iii) Or the MPI_File_write function has not to use the write
> > function in
> > the "continues" way on the data and shoul
> enabled libibverbs for max benefit, etc.).
Yep.
Will prepare a text, do You need it in HTML, or plain-text?
Thanks,
Rainer
--
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
HLRS Tel: ++4
is on, --enable-debug should be on as well to make
sense.
--
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
HLRS Tel: ++49 (0)711-685 6 5858
Nobelstrasse 19 Fax: ++49 (0)711-685 6
s ompi_mpi_abort).
OK to check in?
With best regards,
Rainer
--
--------
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
High Performance Computing Tel: ++49 (0)711-685 6 5858
Center Stuttgart (HLRS) Fax: ++49 (0)711-685 6 5832
ution is to move
the pml_base_sendreq.h / pml_base_recv_req.h
into
pml_ob1_irecv.c, and resp. pml_ob1_isend.c
Please see the v15945.
With best regards,
Rainer
--
--------
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
-------
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
High Performance Computing Tel: ++49 (0)711-685 6 5858
Center Stuttgart (HLRS) Fax: ++49 (0)711-685 6 5832
POSTAL:Nobelstrasse 19 email: kel...@hlrs.de
ACTUAL:Allmandring 30, R.
r15137:
> - Add the missing parts: add MPI_REAL2 to the end of the list
> of Fortran datatypes (mpif-common.h) and the list of registered
> datatypes: MOOG(REAL2).
> Configure and Compilation with ia32/gcc just finished, naturally
> without real2.
--
------
w the convertor to go outside the data boundaries. This
> test include * the check for datatype with size zero as well as for
> convertors with a count of zero. */
> -if( convertor->local_size <= *position) {
> +if( OPAL_UNLIKELY(convertor->local_size <= *position) ) {
> c
suggested, the two missing parts are committed.
To the unsuspecting Fortran app, everything should look the same...
With best regards,
Rainer
--
--------
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
High Performance C
nd if anybody cares.
Thanks,
Rainer
--
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
High Performance Computing Tel: ++49 (0)711-685 6 5858
Center Stuttgart (HLRS) Fax: ++49 (0)711-685 6
;if (MPI_Type_create_struct(1,blen,disp,btype,¶m_batch)!=MPI_SUCCESS)
> fprintf(stderr,"MPI_Type_Create_Struct failed.\n");
>if (MPI_Type_commit(¶m_batch)!=MPI_SUCCESS)
> fprintf(stderr,"MPI_Type_Commit failed.\n");
>if (rank==0)
> param=100.;
of the afternoon session, as well.
Thanks,
Rainer
--
--------
Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller
High Performance Computing Tel: ++49 (0)711-685 6 5858
Center Stuttgart (HLRS) Fax: ++49 (0)711-685 6 5832
POSTAL:Nobelstrasse 19 emai
e_list
CU,
Rainer
--
---------
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance Computing Tel: ++49 (0)711-685 5858
Center Stuttgart (HLRS)Fax: ++49 (0)711-685 5832
POSTAL:Nobelstrasse 19 http://www.hlrs.de/people/keller
___________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
-
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance
c:892
May I check in the patch attached below?
Thanks,
Rainer
--
-
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance Computing Tel: ++49 (0)711-685 5858
Center Stuttgart (HLRS)Fax: ++49 (0)71
d with separate components, so you can do "make install"
> > right from the rsh dir) or re-link liborte and re-install that and re-
> > run. The corefile might give something a little more meaningful in
> > this case...?
> >
> > --
> > {+} Jeff Squyres
> > {+} The Open MPI Pr
disappointment, but we must never lose infinite
> hope."
> Martin Luther King
--
-
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance Computing Tel: ++49 (0)711-685 5858
is test.
BTW: the intel-tests failing are in MPI_Group_range_excl3_c.c, right?
Thanks,
Rainer
--
---------
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance Computing Tel: ++49 (0)711-685 5858
Center
the pointer to be
> >> NULL. Was this a static build? I was seeing some weird memory
> >> issues on static builds last night... I'll take a look on odin and
> >> see what I can find.
> >>
> >> Brian
> >>
> >> On Aug 18, 200
e check, can you run ompi_info and send me the results?
>
> Thanks,
>
> Brian
>
> On Aug 18, 2005, at 10:45 AM, Rainer Keller wrote:
> > Hello,
> > see the "same" (well probably not exactly same) thing here in
> > Opteron with
>
ror 1
> >>>>>>>>>[sparkplug]~/ompi >
> >>>>>>>>
> >>>>>>>>Clean SVN checkout this morning with configure:
> >>>>>>>>>[sparkplug]~/ompi > ./configure --enable-static --disable-shared
> >>>>>>>>>--without-threads --prefix=/home/ndebard/local/ompi
> >>>>>>>>>--with-devel-headers
> >>>>>>>>
> >>>>>>>>-- Nathan
> >>>>>>>>Correspondence
> >>>>>>>>---
> >>>>>>>>-- Nathan DeBardeleben, Ph.D.
> >>>>>>>>Los Alamos National Laboratory
> >>>>>>>>Parallel Tools Team
> >>>>>>>>High Performance Computing Environments
> >>>>>>>>phone: 505-667-3428
> >>>>>>>>email: ndeb...@lanl.gov
> >>>>>>>>---
> >>>>>>>>--
> >>>>>>>>
> >>>>>>>>Brian Barrett wrote:
> >>>>>>>>>This is now fixed in SVN. You should no longer need the
> >>>>>>>>>--build=i586... hack to compile 32 bit code on Opterons.
> >>>>>>>>>
> >>>>>>>>>Brian
> >>>>>>>>>
> >>>>>>>>>On Aug 12, 2005, at 3:17 PM, Brian Barrett wrote:
> >>>>>>>>>>On Aug 12, 2005, at 3:13 PM, Nathan DeBardeleben wrote:
> >>>>>>>>>>>We've got a 64bit Linux (SUSE) box here. For a variety of
> >>>>>>>>>>> reasons (Java, JNI, linking in with OMPI libraries, etc which I
> >>>>>>>>>>> won't get into)
> >>>>>>>>>>>I need to compile OMPI 32 bit (or get 64bit versions of a lot of
> >>>>>>>>>>>other
> >>>>>>>>>>>libraries).
> >>>>>>>>>>>I get various compile errors when I try different things, but
> >>>>>>>>>>>first
> >>>>>>>>>>>let
> >>>>>>>>>>>me explain the system we have:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>This goes on and on and on actually. And the 'is incompatible
> >>>>>>>>>>>with
> >>>>>>>>>>>i386:x86-64 output' looks to be repeated for every line before
> >>>>>>>>>>>this
> >>>>>>>>>>>error which actually caused the Make to bomb.
> >>>>>>>>>>>
> >>>>>>>>>>>Any suggestions at all? Surely someone must have tried to force
> >>>>>>>>>>>OMPI to
> >>>>>>>>>>>build in 32bit mode on a 64bit machine.
> >>>>>>>>>>
> >>>>>>>>>>I don't think anyone has tried to build 32 bit on an Opteron,
> >>>>>>>>>> which is the cause of the problems...
> >>>>>>>>>>
> >>>>>>>>>>I think I know how to fix this, but won't happen until later in
> >>>>>>>>>> the weekend. I can't think of a good workaround until then.
> >>>>>>>>>> Well, one possibility is to set the target like you were doing
> >>>>>>>>>> and disable ROMIO. Actually, you'll also need to disable
> >>>>>>>>>> Fortran 77. So something like:
> >>>>>>>>>>
> >>>>>>>>>>./configure [usual options] --build=i586-suse-linux --disable-io-
> >>>>>>>>>>romio --disable-f77
> >>>>>>>>>>
> >>>>>>>>>>might just do the trick.
> >>>>>>>>>>
> >>>>>>>>>>Brian
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>--
> >>>>>>>>>>Brian Barrett
> >>>>>>>>>>Open MPI developer
> >>>>>>>>>>http://www.open-mpi.org/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>___
> >>>>>>>>>>devel mailing list
> >>>>>>>>>>de...@open-mpi.org
> >>>>>>>>>>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>>>>>>
> >>>>>>>>___
> >>>>>>>>devel mailing list
> >>>>>>>>de...@open-mpi.org
> >>>>>>>>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>>>>>
> >>>>>>>___
> >>>>>>>devel mailing list
> >>>>>>>de...@open-mpi.org
> >>>>>>>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>>>>
> >>>>>>___
> >>>>>>devel mailing list
> >>>>>>de...@open-mpi.org
> >>>>>>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>>
> >>>>___
> >>>>devel mailing list
> >>>>de...@open-mpi.org
> >>>>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>>
> >>>___
> >>>devel mailing list
> >>>de...@open-mpi.org
> >>>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>
> >>___
> >>devel mailing list
> >>de...@open-mpi.org
> >>http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> >___
> >devel mailing list
> >de...@open-mpi.org
> >http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
-
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance Computing Tel: ++49 (0)711-685 5858
Center Stuttgart (HLRS) Fax: ++49 (0)711-678 7626
Nobelstrasse 19, R. O0.030http://www.hlrs.de/people/keller
70550 Stuttgart
ersion(s))?
pgi-5.2-4
no 6.0 version...
CU,
Rainer
--
---------
Dipl.-Inf. Rainer Keller email: kel...@hlrs.de
High Performance Computing Tel: ++49 (0)711-685 5858
Center Stuttgart (HLRS) Fax: ++49 (
86 matches
Mail list logo
