Yes, this sounds like a good option. Unfortunately using makefiles seems to preclude using the gui debugger facilities of xcode, or at least I have not discovered the right combination of debug flags for g++ that cause Xcode to debug correctly. Has here anyone successfully done this? e.g., one can create an "external build system" and successfully compile via the makefile, but breakpoints that are then set in xcode are not repsected by the debugger. <br>
<br>Of course, it takes some trickery also to even get xcode to give your mpicxx as an option when building a native project; I've seen references to this for earlier versions of xcode, but haven't tried this with the new 3.1<br>
<br>-thomas<br><br><div class="gmail_quote">On Fri, Dec 19, 2008 at 9:21 AM, Jeff Squyres <span dir="ltr"><<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I haven't used Xcode, but Eric is right: if you set your PATH and simply use the wrapper compiler for the MPI that you choose (e.g., mpicc), the wrapper compiler should pass the relevant -I and -L flags to find the "right" headers and libraries.<br>
<br>
I do this quite frequently on my OS X Leopard laptop; all I do is set the PATH (to ensure that I'm using the right MPI executables), and everything else works out.<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
On Dec 18, 2008, at 6:21 PM, Eric A. Borisch wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thomas,<br>
<br>
You're probably better off using a makefile (which you can have XCode run for you for...) so you can just use the mpicc and mpicxx wrapper scripts to build. (Note that you'll need to set the path environment variable for the make command step within XCode to pick up your preferred mpicc.)<br>
<br>
Eric<br>
<br>
On Thu, Dec 18, 2008 at 11:39 AM, Thomas Blom <<a href="mailto:blomcode@gmail.com" target="_blank">blomcode@gmail.com</a>> wrote:<br>
True for execution paths, but I wanted to ensure I wasn't picking up the wrong header or libs along the way somehow during builds of stuff. This is easy enough in simple makefiles, but in xcode using a native project (which I'm new to) I'm never sure where it is looking first etc and so resort to tricks like hiding files. Apple's version of gcc and ld also behave differently than 'standard' versions of these tools, so hiding or removing all headers/libs/binaries for an sdk seems the safest way to me to ensure they are not getting involved behind the scenes somehow. Again, I'm somewhat new to development on osx.<br>
<br>
-thomas<br>
<br>
<br>
On Thu, Dec 18, 2008 at 7:42 AM, Jeff Squyres <<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>> wrote:<br>
FWIW, you shouldn't even need to "hide" the default MPI that ships with Leopard by putting it in another directory. If you just set your PATH to point to /usr/local/bin before it points to /usr/bin, you should be fine (I do this all the time on my MacBook Pro laptop).<br>
<br>
<br>
<br>
<br>
On Dec 17, 2008, at 9:22 PM, Thomas Blom wrote:<br>
<br>
Thanks. Perhaps that would have worked. What I ended up doing was "hiding" the headers, libs, and exes for the openmpi that came installed on the mac. Then I did the configure, make, and make install again, and it worked.<br>
<br>
-thomas<br>
<br>
On Wed, Dec 17, 2008 at 11:12 PM, Rajeev Thakur <<a href="mailto:thakur@mcs.anl.gov" target="_blank">thakur@mcs.anl.gov</a>> wrote:<br>
Just try logging out and log back in again.<br>
<br>
Rajeev<br>
<br>
From: <a href="mailto:mpich-discuss-bounces@mcs.anl.gov" target="_blank">mpich-discuss-bounces@mcs.anl.gov</a> [mailto:<a href="mailto:mpich-discuss-bounces@mcs.anl.gov" target="_blank">mpich-discuss-bounces@mcs.anl.gov</a>] On Behalf Of Thomas Blom<br>
Sent: Wednesday, December 17, 2008 10:06 PM<br>
To: <a href="mailto:mpich-discuss@mcs.anl.gov" target="_blank">mpich-discuss@mcs.anl.gov</a><br>
Subject: [mpich-discuss] mpich2 / openmpi conflicts on osx 10.5?<br>
<br>
Hello,<br>
<br>
I've successfully used mpich2 on windows and on a couple of other osx machines, but having just built mpich2 from source on a new mac pro I encounter difficulty when trying to run some mpi programs.<br>
<br>
OSX 10.5 ships with OpenMPI apparently, such that there are mpi* programs in /usr/bin<br>
<br>
I accepted the default when configuring/building/installing mpich2, such that it gets installed to /usr/local/bin<br>
<br>
Once I realized that the wrong mpiexec was getting called, I chose to "hide" the /usr/bin versions (not knowing otherwise how to disable or uninstall the openmpi) by just creating a folder _mpi_hidden in /usr/bin and placing all those mpi* programs in there.<br>
<br>
Now when I type "which mpiexec" it correctly states /usr/local/bin/mpiexec (the mpich2 installed version)<br>
<br>
But when I try the example "mpiexec -n 3 hostname" I get the error message<br>
<br>
-bash: /usr/bin/mpiexec: No such file or directory<br>
<br>
I'm not clear about what's going on here. Is the python mpiexec in /usr/local/bin trying to call the preexisting mpiexec in /usr/bin?<br>
<br>
The original mpiexec in /usr/bin reports this when run without argument<br>
<br>
mpiexec (OpenRTE) 1.2.3<br>
<usage/flags snipped><br>
<br>
Thanks for any help untangling this problem. I'm not sure why I didn't run into this problem on a new imac that was setup similarly a couple months ago...Perhaps OS preinstalled on that system was an earlier rev of 10.5. For whatever reason it does not have any mpi programs in /usr/bin.<br>
<br>
-thomas blom<br>
ices/ut austin<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Jeff Squyres<br>
Cisco Systems<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Eric A. Borisch<br>
<a href="mailto:eborisch@ieee.org" target="_blank">eborisch@ieee.org</a><br>
<br>
Howard Roark laughed.<br>
</blockquote>
<br>
<br></div></div><font color="#888888">
-- <br>
Jeff Squyres<br>
Cisco Systems<br>
<br>
</font></blockquote></div><br>