Hmm; I'm not sure.
distclean will fail in a tarball or SVN checkout if you do --enable-
contrib-no-build=vt. So it's not a developer-only artifact.
I don't know what the Right solution is, though. :-\
On Feb 12, 2008, at 9:22 AM, Josh Hursey wrote:
Good points about 'distclean' versus '
Good points about 'distclean' versus 'clean'. For the make distclean
case then I think it is ok if we fail here since it is not a full
'make dist' that I was working with originally.
Sorry for the distraction.
Cheers,
Josh
On Feb 12, 2008, at 6:52 AM, Andreas Knüpfer wrote:
On Monday 11 F
On Monday 11 February 2008, Josh Hursey wrote:
> I've been noticing another problem with the VT integration. If you do
> a "./configure --enable-contrib-no-build=vt" a subsequent 'make
> distclean' will fail in contrib/vt. The 'make distclean' will succeed
> with VT enabled (default).
>
hm, tricky
* Josh Hursey wrote on Mon, Feb 11, 2008 at 07:31:25PM CET:
> I've been noticing another problem with the VT integration. If you do
> a "./configure --enable-contrib-no-build=vt" a subsequent 'make
> distclean' will fail in contrib/vt. The 'make distclean' will succeed
> with VT enabled (defa
I've been noticing another problem with the VT integration. If you do
a "./configure --enable-contrib-no-build=vt" a subsequent 'make
distclean' will fail in contrib/vt. The 'make distclean' will succeed
with VT enabled (default).
---
Making distclean in contrib/vt
make
Sun has no objections to the vt integration.
--td
Jeff Squyres wrote:
Truly weird; I am now unable to reproduce the problem as well. Can
you think of any dumb user-level error that I could have done to
create this problem? It was very repeatable the other day. :-(
Oh well. Barring any o
Truly weird; I am now unable to reproduce the problem as well. Can
you think of any dumb user-level error that I could have done to
create this problem? It was very repeatable the other day. :-(
Oh well. Barring any objections from Sun, I say that this stuff
should *finally* be merged b
Hi Jeff,
unfortunalety, also for this problem I need some more information,
because I could
not reproduce this error on our Leopard...
Please add the option '-vt:verbose' to the compile command in order that
I can see what
the VT's compiler wrapper do. Futhermore, could you send me the source
fil
I am able to compile now on OS X -- great!
However, I seem to get some weird errors when running on Leopard:
[13:14] beezle:~/tmp/foo % mpicc-vt ../hello.c -o hello
[13:14] beezle:~/tmp/foo % nm hello > hello.nm
[13:14] beezle:~/tmp/foo % setenv VT_NMFILE ~/tmp/foo/hello.nm
[13:14] beezle:~/tmp/
Hi Jeff,
I could reproduce the linker problem with the sf.net GCC. Thanks for
your hint.
A header include was missing for STL's functional objects. :-(
Matthias
On Do, 2008-01-10 at 13:21 -0500, Jeff Squyres wrote:
> On Jan 10, 2008, at 10:19 AM, Andreas Knüpfer wrote:
>
> > unfortunately, w
On Jan 10, 2008, at 10:19 AM, Andreas Knüpfer wrote:
unfortunately, we're unable to reproduce this error. Could you pass
some more
information about your configure command line? This was done with
gcc 4.2 on
mac os X, wasn't it?
I'm on Leopard on my MBP with:
./configure --prefix=/Users/j
Hi Jeff,
unfortunately, we're unable to reproduce this error. Could you pass some more
information about your configure command line? This was done with gcc 4.2 on
mac os X, wasn't it?
Thanks, Andreas
On Tuesday 08 January 2008, Jeff Squyres wrote:
> From today's head (r17068):
>
> Making all
From today's head (r17068):
Making all in vtunify
g++ -fopenmp -DVT_OMP -g -Wall -Wundef -Wno-long-long -finline-
functions -fopenmp -Wl,-u,_munmap -Wl,-multiply_defined,suppress -o
vtunify vtunify-vt_unify.o vtunify-vt_unify_defs.o vtunify-
vt_unify_defs_hdlr.o vtunify-vt_unify_events.o vtu
Have you tested building this with vpath? I am seeing the following
errors during make all (while using a vpath directory):
Making all in doc
gmake[5]: Entering directory
`/workspace/tdd/ct7/ompi-ws-vt/ompi-vt-integration/builds/ompi-vt-integration/config-data/SunOS/sparc/2007.12.05/64/ompi/co
OS X enforces a no duplicate symbol rule when flat namespaces are in use
(the default on OS X). If all the libraries are two-level namespace
libraries (libSystem.dylib, aka libm.dylib is two-level), then duplicate
symbols are mostly ok.
Libtool by default forces a flat namespace in sharedlibr
I know that OS X's linker is quite different than the Linux linker --
you might want to dig into the ld(1) man page on OS X as a starting
point, and/or consult developer.apple.com for more details.
On Dec 5, 2007, at 10:04 AM, Matthias Jurenz wrote:
Hi Jeff,
I have added checks for the fu
I haven't tried to debug the following but I am getting the following
errors when building the vt-integration tmp branch on Solaris. So I
don't think the branch is ready for putback yet.
--td
cc -DHAVE_CONFIG_H -I. -I..
-I/workspace/tdd/ct7/ompi-ws-vt/ompi-vt-integration/builds/ompi-vt-inte
Unfortunately, VT fails to compile on OS X Leopard (10.5.1).
- Is there a way to remove the anonymous variadic macros?
- open64, creat64, etc. do not appear to exist on OS X.
I don't know if you want to go through the work of supporting OS X or
not -- if not, we should put in appropriate contr
I merged the current SVN trunk down to the vt-integration branch this
morning (e.g., without the recent changes for OS X Leopard on the
trunk, I couldn't build on my Mac laptop). However, because SVN
merges take so long (this one took 1.5 hours), it ate up all my time
before I have to leav
Excellent -- thanks.
On Sep 21, 2007, at 11:30 AM, Andreas Knüpfer wrote:
On Friday 21 September 2007, Jeff Squyres wrote:
Per an idea that came up recently, can we make it so that ompi_info
reports the version of VT that is integrated into Open MPI?
good idea, we'll pick it up real soon
An
On Friday 21 September 2007, Jeff Squyres wrote:
> Per an idea that came up recently, can we make it so that ompi_info
> reports the version of VT that is integrated into Open MPI?
good idea, we'll pick it up real soon
Andreas
--
Dipl. Math. Andreas Knuepfer,
Center for Information Services an
Per an idea that came up recently, can we make it so that ompi_info
reports the version of VT that is integrated into Open MPI?
--
Jeff Squyres
Cisco Systems
22 matches
Mail list logo
