Re: [OMPI devel] dummy component warnings
Short version = MTT turned up a problem with -std=gnu99 on OS X Leopard, which ships with the gcc 4.0 compiler (OS X Snow Leopard ships with gcc 4.2, and doesn't have a problem). Does anyone have gcc 4.0 on Linux? I'm wondering if the same problem would occur. More details: = >From our friends at Absoft: - The -std=gnu99 is causing the problem when used with gcc-4.0 ( the default on Leopard with Apple's XCode 3.1 development tools ): BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s BigMac:ompi cag$ On Snow Leopard with Apple's XCode 3.2 development tools, the default compiler is 4.2. - The compile line he's talking about in particular is from a configure test in opal/config/opal_config_asm.m4, where we're looking for assembly global symbols. The source that we're trying to compile is: - .text # _gsym_test_func .globl _gsym_test_func _gsym_test_func: # _gsym_test_func - (configure tries a few prefixes) But the "#" token with the -std=gnu99 option is causing failures where it shouldn't (i.e., it causes configure to abort because all the assembly tests looking for the global symbols error out due to the # token. So I think we either need to find a workaround for this assembly test or whack the idea of the C99 stuff. :-( On Jan 24, 2011, at 10:29 AM, Nathan Hjelm wrote: > No, they didn't get added (adding them now). I didn't get a chance to add > them over the weekend. > > -Nathan > > On Mon, 24 Jan 2011, Jeff Squyres wrote: > >> I'm getting these: >> >> CC dummy_component.lo >> dummy_component.c:25: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:28: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:29: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:30: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:31: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:33: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:34: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:35: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:37: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c:39: warning: ISO C90 forbids specifying subobject to >> initialize >> dummy_component.c: In function ‘component_open’: >> dummy_component.c:45: warning: unused variable ‘c’ >> dummy.c:67: warning: ISO C90 forbids specifying subobject to initialize >> dummy.c:68: warning: ISO C90 forbids specifying subobject to initialize >> dummy.c:69: warning: ISO C90 forbids specifying subobject to initialize >> dummy.c:70: warning: ISO C90 forbids specifying subobject to initialize >> CCLD mca_debugger_dummy.la >> >> Did the autoconf tests not get added? >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> ___ >> 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 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] dummy component warnings
Looks like a bug in Apple's gcc 4.0. I tried the source with gcc 3.4.6 and gcc 4.1.2 on Linux and did not see that error. I will take a look and see if there is a simple fix to get around this apparent compiler bug. -Nathan On Tue, 25 Jan 2011, Jeff Squyres wrote: Short version = MTT turned up a problem with -std=gnu99 on OS X Leopard, which ships with the gcc 4.0 compiler (OS X Snow Leopard ships with gcc 4.2, and doesn't have a problem). Does anyone have gcc 4.0 on Linux? I'm wondering if the same problem would occur. More details: = From our friends at Absoft: - The -std=gnu99 is causing the problem when used with gcc-4.0 ( the default on Leopard with Apple's XCode 3.1 development tools ): BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s BigMac:ompi cag$ On Snow Leopard with Apple's XCode 3.2 development tools, the default compiler is 4.2. - The compile line he's talking about in particular is from a configure test in opal/config/opal_config_asm.m4, where we're looking for assembly global symbols. The source that we're trying to compile is: - .text # _gsym_test_func .globl _gsym_test_func _gsym_test_func: # _gsym_test_func - (configure tries a few prefixes) But the "#" token with the -std=gnu99 option is causing failures where it shouldn't (i.e., it causes configure to abort because all the assembly tests looking for the global symbols error out due to the # token. So I think we either need to find a workaround for this assembly test or whack the idea of the C99 stuff. :-( On Jan 24, 2011, at 10:29 AM, Nathan Hjelm wrote: No, they didn't get added (adding them now). I didn't get a chance to add them over the weekend. -Nathan On Mon, 24 Jan 2011, Jeff Squyres wrote: I'm getting these: CC dummy_component.lo dummy_component.c:25: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:28: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:29: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:30: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:31: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:33: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:34: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:35: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:37: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:39: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c: In function ‘component_open’: dummy_component.c:45: warning: unused variable ‘c’ dummy.c:67: warning: ISO C90 forbids specifying subobject to initialize dummy.c:68: warning: ISO C90 forbids specifying subobject to initialize dummy.c:69: warning: ISO C90 forbids specifying subobject to initialize dummy.c:70: warning: ISO C90 forbids specifying subobject to initialize CCLD mca_debugger_dummy.la Did the autoconf tests not get added? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] dummy component warnings
I have gcc-4.0.0 on Linux built from unmodified FSF sources. I will try to reproduce. -Paul On 1/25/2011 1:47 PM, Nathan Hjelm wrote: Looks like a bug in Apple's gcc 4.0. I tried the source with gcc 3.4.6 and gcc 4.1.2 on Linux and did not see that error. I will take a look and see if there is a simple fix to get around this apparent compiler bug. -Nathan On Tue, 25 Jan 2011, Jeff Squyres wrote: Short version = MTT turned up a problem with -std=gnu99 on OS X Leopard, which ships with the gcc 4.0 compiler (OS X Snow Leopard ships with gcc 4.2, and doesn't have a problem). Does anyone have gcc 4.0 on Linux? I'm wondering if the same problem would occur. More details: = From our friends at Absoft: - The -std=gnu99 is causing the problem when used with gcc-4.0 ( the default on Leopard with Apple's XCode 3.1 development tools ): BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s BigMac:ompi cag$ On Snow Leopard with Apple's XCode 3.2 development tools, the default compiler is 4.2. - The compile line he's talking about in particular is from a configure test in opal/config/opal_config_asm.m4, where we're looking for assembly global symbols. The source that we're trying to compile is: - .text # _gsym_test_func .globl _gsym_test_func _gsym_test_func: # _gsym_test_func - (configure tries a few prefixes) But the "#" token with the -std=gnu99 option is causing failures where it shouldn't (i.e., it causes configure to abort because all the assembly tests looking for the global symbols error out due to the # token. So I think we either need to find a workaround for this assembly test or whack the idea of the C99 stuff. :-( On Jan 24, 2011, at 10:29 AM, Nathan Hjelm wrote: No, they didn't get added (adding them now). I didn't get a chance to add them over the weekend. -Nathan On Mon, 24 Jan 2011, Jeff Squyres wrote: I'm getting these: CC dummy_component.lo dummy_component.c:25: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:28: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:29: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:30: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:31: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:33: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:34: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:35: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:37: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c:39: warning: ISO C90 forbids specifying subobject to initialize dummy_component.c: In function 'component_open': dummy_component.c:45: warning: unused variable 'c' dummy.c:67: warning: ISO C90 forbids specifying subobject to initialize dummy.c:68: warning: ISO C90 forbids specifying subobject to initialize dummy.c:69: warning: ISO C90 forbids specifying subobject to initialize dummy.c:70: warning: ISO C90 forbids specifying subobject to initialize CCLD mca_debugger_dummy.la Did the autoconf tests not get added? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ 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 -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group HPC Research Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Re: [OMPI devel] dummy component warnings
I can confirm that the problem appears specific to Apple's compiler.
Since the failure was reported to be configure-time, that took less time
to check up on that I'd expected.
What I find is that gcc-4.0.0 on Linux/x86 *does* fail the
"#_gsym_test_func" test, but for the RIGHT reason, and then goes on to
pass the next test case with the proper form of global symbol. The
relevent portion of config.log appears below.
-Paul
configure:27399: checking prefix for global symbol labels
configure: trying _
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -c conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest > conftest.link
2>&1
configure:27458: $? = 1
conftest_c.o: In function `main':
conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
collect2: ld returned 1 exit status
configure: failed C program was:
#ifdef __cplusplus
extern "C" {
#endif
void gsym_test_func(void);
#ifdef __cplusplus
}
#endif
int
main()
{
gsym_test_func();
return 0;
}
configure: failed ASM program was:
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
configure: trying
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -c conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest > conftest.link
2>&1
configure:27458: $? = 0
configure:27496: result:
On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
I have gcc-4.0.0 on Linux built from unmodified FSF sources.
I will try to reproduce.
-Paul
On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
Looks like a bug in Apple's gcc 4.0. I tried the source with gcc
3.4.6 and gcc 4.1.2 on Linux and did not see that error.
I will take a look and see if there is a simple fix to get around
this apparent compiler bug.
-Nathan
On Tue, 25 Jan 2011, Jeff Squyres wrote:
Short version
=
MTT turned up a problem with -std=gnu99 on OS X Leopard, which ships
with the gcc 4.0 compiler (OS X Snow Leopard ships with gcc 4.2, and
doesn't have a problem). Does anyone have gcc 4.0 on Linux? I'm
wondering if the same problem would occur.
More details:
=
From our friends at Absoft:
-
The -std=gnu99 is causing the problem when used with gcc-4.0 ( the
default on Leopard with Apple's XCode 3.1 development tools ):
BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s
conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func
conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func
BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s
conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func
conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func
BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s
BigMac:ompi cag$
On Snow Leopard with Apple's XCode 3.2 development tools, the
default compiler is 4.2.
-
The compile line he's talking about in particular is from a
configure test in opal/config/opal_config_asm.m4, where we're
looking for assembly global symbols. The source that we're trying
to compile is:
-
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
-
(configure tries a few prefixes)
But the "#" token with the -std=gnu99 option is causing failures
where it shouldn't (i.e., it causes configure to abort because all
the assembly tests looking for the global symbols error out due to
the # token.
So I think we either need to find a workaround for this assembly
test or whack the idea of the C99 stuff. :-(
On Jan 24, 2011, at 10:29 AM, Nathan Hjelm wrote:
No, they didn't get added (adding them now). I didn't get a chance
to add them over the weekend.
-Nathan
On Mon, 24 Jan 2011, Jeff Squyres wrote:
I'm getting these:
CC dummy_component.lo
dummy_component.c:25: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:28: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:29: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:30: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:31: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:33: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:34: warning: ISO C90 forbids specifying
subobject to initialize
dummy_component.c:35: warning: ISO C90 forbids specifying
subobject to initializ
Re: [OMPI devel] dummy component warnings
Ok, then there are two possible simple fixes:
- Strip -std from CCASFLAGS if Apple's gcc 4.0 is encountered, or
- Always strip -std from CCASFLAGS. The flag shouln't have any effect when
compiling assembly.
-Nathan
HPC-3, LANL
On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
I can confirm that the problem appears specific to Apple's compiler.
Since the failure was reported to be configure-time, that took less time to
check up on that I'd expected.
What I find is that gcc-4.0.0 on Linux/x86 *does* fail the "#_gsym_test_func"
test, but for the RIGHT reason, and then goes on to
pass the next test case with the proper form of global symbol. The relevent
portion of config.log appears below.
-Paul
configure:27399: checking prefix for global symbol labels
configure: trying _
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -c
conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -I.
conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest >
conftest.link 2>&1
configure:27458: $? = 1
conftest_c.o: In function `main':
conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
collect2: ld returned 1 exit status
configure: failed C program was:
#ifdef __cplusplus
extern "C" {
#endif
void gsym_test_func(void);
#ifdef __cplusplus
}
#endif
int
main()
{
gsym_test_func();
return 0;
}
configure: failed ASM program was:
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
configure: trying
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -c
conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -I.
conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest >
conftest.link 2>&1
configure:27458: $? = 0
configure:27496: result:
On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
I have gcc-4.0.0 on Linux built from unmodified FSF sources.
I will try to reproduce.
-Paul
On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
Looks like a bug in Apple's gcc 4.0. I tried the source with gcc
3.4.6 and gcc 4.1.2 on Linux and did not
see that error.
I will take a look and see if there is a simple fix to get around
this apparent compiler bug.
-Nathan
On Tue, 25 Jan 2011, Jeff Squyres wrote:
Short version
=
MTT turned up a problem with -std=gnu99 on OS X Leopard,
which ships with the gcc 4.0
compiler (OS X Snow Leopard ships with gcc 4.2, and doesn't
have a problem). Does anyone
have gcc 4.0 on Linux? I'm wondering if the same problem
would occur.
More details:
=
From our friends at Absoft:
-
The -std=gnu99 is causing the problem when used with gcc-4.0
( the default on Leopard with
Apple's XCode 3.1 development tools ):
BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s
conftest.s:2:3: error: invalid preprocessing directive
#_gsym_test_func
conftest.s:5:3: error: invalid preprocessing directive
#_gsym_test_func
BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s
conftest.s:2:3: error: invalid preprocessing directive
#_gsym_test_func
conftest.s:5:3: error: invalid preprocessing directive
#_gsym_test_func
BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s
BigMac:ompi cag$
On Snow Leopard with Apple's XCode 3.2 development tools, the
default compiler is 4.2.
-
The compile line he's talking about in particular is from a
configure test in
opal/config/opal_config_asm.m4, where we're looking for
assembly global symbols. The source
that we're trying to compile is:
-
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
-
(configure tries a few prefixes)
But the "#" token with the -std=gnu99 option is causing
failures where it shouldn't (i.e., it
causes configure to abort because all the assembly tests
looking for the global symbols error
out due to the # token.
So I think we either n
Re: [OMPI devel] dummy component warnings
I found a root cause and a simpler/better simple fix:
From manpage for gcc on Linux:
file.s
Assembler code.
And from Darwin:
file.s
Assembler code. Apple's version of GCC runs the
preprocessor on these files as well as
those ending in .S.
So the problem/difference is that Apple insists on passing the .s
through the preprocessor by default when FSF's gcc does not.
The fix appears to be an explict "-xassembler":
$ cat foo.s
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
$ gcc -std=c99 -c foo.s
foo.s:2:3: error: invalid preprocessing directive #_gsym_test_func
foo.s:5:3: error: invalid preprocessing directive #_gsym_test_func
$ gcc -std=c99 -c -xassembler foo.s
[no output]
-Paul
On 1/25/2011 2:48 PM, Nathan Hjelm wrote:
Ok, then there are two possible simple fixes:
- Strip -std from CCASFLAGS if Apple's gcc 4.0 is encountered, or
- Always strip -std from CCASFLAGS. The flag shouln't have any effect
when compiling assembly.
-Nathan
HPC-3, LANL
On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
I can confirm that the problem appears specific to Apple's compiler.
Since the failure was reported to be configure-time, that took less
time to check up on that I'd expected.
What I find is that gcc-4.0.0 on Linux/x86 *does* fail the
"#_gsym_test_func" test, but for the RIGHT reason, and then goes on to
pass the next test case with the proper form of global symbol. The
relevent portion of config.log appears below.
-Paul
configure:27399: checking prefix for global symbol labels
configure: trying _
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -c conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest >
conftest.link 2>&1
configure:27458: $? = 1
conftest_c.o: In function `main':
conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
collect2: ld returned 1 exit status
configure: failed C program was:
#ifdef __cplusplus
extern "C" {
#endif
void gsym_test_func(void);
#ifdef __cplusplus
}
#endif
int
main()
{
gsym_test_func();
return 0;
}
configure: failed ASM program was:
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
configure: trying
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -c conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest >
conftest.link 2>&1
configure:27458: $? = 0
configure:27496: result:
On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
I have gcc-4.0.0 on Linux built from unmodified FSF sources.
I will try to reproduce.
-Paul
On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
Looks like a bug in Apple's gcc 4.0. I tried the source
with gcc 3.4.6 and gcc 4.1.2 on Linux and did not
see that error.
I will take a look and see if there is a simple fix to
get around this apparent compiler bug.
-Nathan
On Tue, 25 Jan 2011, Jeff Squyres wrote:
Short version
=
MTT turned up a problem with -std=gnu99 on OS X
Leopard, which ships with the gcc 4.0
compiler (OS X Snow Leopard ships with gcc 4.2, and
doesn't have a problem). Does anyone
have gcc 4.0 on Linux? I'm wondering if the same
problem would occur.
More details:
=
From our friends at Absoft:
-
The -std=gnu99 is causing the problem when used
with gcc-4.0 ( the default on Leopard with
Apple's XCode 3.1 development tools ):
BigMac:ompi cag$ gcc --version -std=gnu99 -c
conftest.s
conftest.s:2:3: error: invalid preprocessing
directive #_gsym_test_func
conftest.s:5:3: error: invalid preprocessing
directive #_gsym_test_func
BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s
conftest.s:2:3: error: invalid preprocessing
directive #_gsym_test_func
conftest.s:5:3: error: invalid preprocessing
directive #_gsym_test_func
BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s
BigMac:ompi cag$
On Snow Leopard with Apple's XCode 3.2 development
tools, the default compiler is 4.2.
-
Re: [OMPI devel] OMPI-MIGRATE error
Can you try with the current trunk head (r24296)? I just committed a fix for the C/R functionality in which restarts were getting stuck. This will likely affect the migration functionality, but I have not had an opportunity to test just yet. Another thing to check is that prelink is turned off on all of your machines. https://upc-bugs.lbl.gov//blcr/doc/html/FAQ.html#prelink Let me know if the problem persists, and I'll dig into a bit more. Thanks, Josh On Jan 24, 2011, at 11:37 AM, Hugo Meyer wrote: > Hello @ll > > I've got a problem when i try to use the ompi-migrate command. > > What i'm doing is execute for example the next application in one node of a > cluster (both process wil run on the same node): > > mpirun -np 2 -am ft-enable-cr ./whoami 10 10 > > Then in the same node i try to migrate the processes to another node: > > ompi-migrate -x node9 -t node3 14914 > > And then i get this message: > > [clus9:15620] *** Process received signal *** > [clus9:15620] Signal: Segmentation fault (11) > [clus9:15620] Signal code: Address not mapped (1) > [clus9:15620] Failing at address: (nil) > [clus9:15620] [ 0] /lib64/libpthread.so.0 [0x2c0b8d40] > [clus9:15620] *** End of error message *** > Segmentation fault > > I assume that maybe there is something wrong with the thread level, but i > have configured the open-mpi like this: > > ../configure --prefix=/home/hmeyer/desarrollo/ompi-code/binarios/ > --enable-debug --enable-debug-symbols --enable-trace --with-ft=cr > --disable-ipv6 --enable-opal-multi-threads --enable-ft-thread --without-hwloc > --disable-vt --with-blcr=/soft/blcr-0.8.2/ > --with-blcr-libdir=/soft/blcr-0.8.2/lib/ > > The checkpoint and restart works fine, but when i restore an application that > has more than one process, this one is restored and executed until the last > line before MPI_FINALIZE(), but the processes never finalize, i assume that > they never call the MPI_FINALIZE(), but with one process ompi-checkpoint and > ompi-restart work great. > > Best regards. > > Hugo Meyer > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey
Re: [OMPI devel] dummy component warnings
Wow, its a feature, not a bug. Its strange that it works without the
-xassembler when using gcc 4.2.
-Nathan
HPC-3, LANL
On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
I found a root cause and a simpler/better simple fix:
From manpage for gcc on Linux:
file.s
Assembler code.
And from Darwin:
file.s
Assembler code. Apple's version of GCC runs the preprocessor
on these files as well as
those ending in .S.
So the problem/difference is that Apple insists on passing the .s through the
preprocessor by default when FSF's gcc does not.
The fix appears to be an explict "-xassembler":
$ cat foo.s
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
$ gcc -std=c99 -c foo.s
foo.s:2:3: error: invalid preprocessing directive #_gsym_test_func
foo.s:5:3: error: invalid preprocessing directive #_gsym_test_func
$ gcc -std=c99 -c -xassembler foo.s
[no output]
-Paul
On 1/25/2011 2:48 PM, Nathan Hjelm wrote:
Ok, then there are two possible simple fixes:
- Strip -std from CCASFLAGS if Apple's gcc 4.0 is encountered, or
- Always strip -std from CCASFLAGS. The flag shouln't have any effect
when compiling assembly.
-Nathan
HPC-3, LANL
On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
I can confirm that the problem appears specific to Apple's compiler.
Since the failure was reported to be configure-time, that took less
time to check up on that I'd
expected.
What I find is that gcc-4.0.0 on Linux/x86 *does* fail the
"#_gsym_test_func" test, but for the RIGHT
reason, and then goes on to
pass the next test case with the proper form of global symbol. The
relevent portion of config.log
appears below.
-Paul
configure:27399: checking prefix for global symbol labels
configure: trying _
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -c conftest.s
>conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -I. conftest_c.c -c
> conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o
conftest.o -o conftest >
conftest.link 2>&1
configure:27458: $? = 1
conftest_c.o: In function `main':
conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
collect2: ld returned 1 exit status
configure: failed C program was:
#ifdef __cplusplus
extern "C" {
#endif
void gsym_test_func(void);
#ifdef __cplusplus
}
#endif
int
main()
{
gsym_test_func();
return 0;
}
configure: failed ASM program was:
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
configure: trying
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -c conftest.s
>conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing -I. conftest_c.c -c
> conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o
conftest.o -o conftest >
conftest.link 2>&1
configure:27458: $? = 0
configure:27496: result:
On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
I have gcc-4.0.0 on Linux built from unmodified FSF sources.
I will try to reproduce.
-Paul
On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
Looks like a bug in Apple's gcc 4.0. I tried the source
with gcc 3.4.6 and gcc 4.1.2 on Linux
and did not
see that error.
I will take a look and see if there is a simple fix to
get around this apparent compiler bug.
-Nathan
On Tue, 25 Jan 2011, Jeff Squyres wrote:
Short version
=
MTT turned up a problem with -std=gnu99 on OS X
Leopard, which ships with the gcc 4.0
compiler (OS X Snow Leopard ships with gcc 4.2,
and doesn't have a problem). Does
anyone
have gcc 4.0 on Linux? I'm wondering if th
Re: [OMPI devel] dummy component warnings
FWIW, we might have a deal breaker back here at Cisco...
The OMPI code base is being used in an embedded environment with a toolchain
that (we think) was derived from gcc 3.x. It seems to totally hate the
-std=gnu99 flag. :-(
Further, it is extremely unlikely that the toolchain will be upgraded (this is
something beyond our control).
Cisco must therefore vote "thumbs down" on the C99 stuff.
Sorry guys! :-(
On Jan 25, 2011, at 5:51 PM, Paul H. Hargrove wrote:
> I found a root cause and a simpler/better simple fix:
>
> From manpage for gcc on Linux:
>>file.s
>>Assembler code.
>
> And from Darwin:
>
>>file.s
>>Assembler code. Apple's version of GCC runs the preprocessor on
>> these files as well as
>>those ending in .S.
>
> So the problem/difference is that Apple insists on passing the .s through the
> preprocessor by default when FSF's gcc does not.
> The fix appears to be an explict "-xassembler":
>
> $ cat foo.s
> .text
> # _gsym_test_func
> .globl _gsym_test_func
> _gsym_test_func:
> # _gsym_test_func
>
> $ gcc -std=c99 -c foo.s
> foo.s:2:3: error: invalid preprocessing directive #_gsym_test_func
> foo.s:5:3: error: invalid preprocessing directive #_gsym_test_func
>
> $ gcc -std=c99 -c -xassembler foo.s
> [no output]
>
> -Paul
>
>
> On 1/25/2011 2:48 PM, Nathan Hjelm wrote:
>> Ok, then there are two possible simple fixes:
>> - Strip -std from CCASFLAGS if Apple's gcc 4.0 is encountered, or
>> - Always strip -std from CCASFLAGS. The flag shouln't have any effect when
>> compiling assembly.
>>
>> -Nathan
>> HPC-3, LANL
>>
>> On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
>>
>>> I can confirm that the problem appears specific to Apple's compiler.
>>>
>>> Since the failure was reported to be configure-time, that took less time to
>>> check up on that I'd expected.
>>> What I find is that gcc-4.0.0 on Linux/x86 *does* fail the
>>> "#_gsym_test_func" test, but for the RIGHT reason, and then goes on to
>>> pass the next test case with the proper form of global symbol. The
>>> relevent portion of config.log appears below.
>>>
>>> -Paul
>>>
>>> configure:27399: checking prefix for global symbol labels
>>> configure: trying _
>>> configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
>>> -fno-strict-aliasing -c conftest.s >conftest.out 2>&1
>>> configure:27442: $? = 0
>>> configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
>>> -fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
>>> configure:27450: $? = 0
>>> configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
>>> -fno-strict-aliasing conftest_c.o conftest.o -o conftest>
>>> conftest.link 2>&1
>>> configure:27458: $? = 1
>>> conftest_c.o: In function `main':
>>> conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
>>> collect2: ld returned 1 exit status
>>> configure: failed C program was:
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>> void gsym_test_func(void);
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>> int
>>> main()
>>> {
>>> gsym_test_func();
>>> return 0;
>>> }
>>> configure: failed ASM program was:
>>>
>>> .text
>>> # _gsym_test_func
>>> .globl _gsym_test_func
>>> _gsym_test_func:
>>> # _gsym_test_func
>>>
>>> configure: trying
>>> configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
>>> -fno-strict-aliasing -c conftest.s >conftest.out 2>&1
>>> configure:27442: $? = 0
>>> configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
>>> -fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
>>> configure:27450: $? = 0
>>> configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
>>> -fno-strict-aliasing conftest_c.o conftest.o -o conftest>
>>> conftest.link 2>&1
>>> configure:27458: $? = 0
>>> configure:27496: result:
>>>
>>>
>>>
>>>
>>> On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
>>> I have gcc-4.0.0 on Linux built from unmodified FSF sources.
>>> I will try to reproduce.
>>>
>>> -Paul
>>>
>>> On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
>>> Looks like a bug in Apple's gcc 4.0. I tried the source with
>>> gcc 3.4.6 and gcc 4.1.2 on Linux and did not
>>> see that error.
>>>
>>> I will take a look and see if there is a simple fix to get
>>> around this apparent compiler bug.
>>>
>>> -Nathan
>>>
>>> On Tue, 25 Jan 2011, Jeff Squyres wrote:
>>>
>>> Short version
>>> =
>>>
>>> MTT turned up a problem with -std=gnu99 on OS X Leopard,
>>> which ships with the gcc 4.0
>>> compiler (OS X Snow Leopard ships with gcc 4.2, and
>>> doesn't have a problem). Does anyone
>>> have gcc 4.0 on Linux? I'm wondering if the same problem
>>> would occur.
>>>
>>> More details:
>>>
Re: [OMPI devel] dummy component warnings
Damn! I will remove the offending code now.
-Nathan
HPC-3, LANL
On Tue, 25 Jan 2011, Jeff Squyres wrote:
FWIW, we might have a deal breaker back here at Cisco...
The OMPI code base is being used in an embedded environment with a toolchain
that (we think) was derived from gcc 3.x. It seems to totally hate the
-std=gnu99 flag. :-(
Further, it is extremely unlikely that the toolchain will be upgraded (this is
something beyond our control).
Cisco must therefore vote "thumbs down" on the C99 stuff.
Sorry guys! :-(
On Jan 25, 2011, at 5:51 PM, Paul H. Hargrove wrote:
I found a root cause and a simpler/better simple fix:
From manpage for gcc on Linux:
file.s
Assembler code.
And from Darwin:
file.s
Assembler code. Apple's version of GCC runs the preprocessor on
these files as well as
those ending in .S.
So the problem/difference is that Apple insists on passing the .s through the
preprocessor by default when FSF's gcc does not.
The fix appears to be an explict "-xassembler":
$ cat foo.s
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
$ gcc -std=c99 -c foo.s
foo.s:2:3: error: invalid preprocessing directive #_gsym_test_func
foo.s:5:3: error: invalid preprocessing directive #_gsym_test_func
$ gcc -std=c99 -c -xassembler foo.s
[no output]
-Paul
On 1/25/2011 2:48 PM, Nathan Hjelm wrote:
Ok, then there are two possible simple fixes:
- Strip -std from CCASFLAGS if Apple's gcc 4.0 is encountered, or
- Always strip -std from CCASFLAGS. The flag shouln't have any effect when
compiling assembly.
-Nathan
HPC-3, LANL
On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
I can confirm that the problem appears specific to Apple's compiler.
Since the failure was reported to be configure-time, that took less time to
check up on that I'd expected.
What I find is that gcc-4.0.0 on Linux/x86 *does* fail the "#_gsym_test_func"
test, but for the RIGHT reason, and then goes on to
pass the next test case with the proper form of global symbol. The relevent
portion of config.log appears below.
-Paul
configure:27399: checking prefix for global symbol labels
configure: trying _
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -c
conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -I.
conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest>
conftest.link 2>&1
configure:27458: $? = 1
conftest_c.o: In function `main':
conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
collect2: ld returned 1 exit status
configure: failed C program was:
#ifdef __cplusplus
extern "C" {
#endif
void gsym_test_func(void);
#ifdef __cplusplus
}
#endif
int
main()
{
gsym_test_func();
return 0;
}
configure: failed ASM program was:
.text
# _gsym_test_func
.globl _gsym_test_func
_gsym_test_func:
# _gsym_test_func
configure: trying
configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -c
conftest.s >conftest.out 2>&1
configure:27442: $? = 0
configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -I.
conftest_c.c -c > conftest.cmpl 2>&1
configure:27450: $? = 0
configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest_c.o conftest.o -o conftest>
conftest.link 2>&1
configure:27458: $? = 0
configure:27496: result:
On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
I have gcc-4.0.0 on Linux built from unmodified FSF sources.
I will try to reproduce.
-Paul
On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
Looks like a bug in Apple's gcc 4.0. I tried the source with gcc
3.4.6 and gcc 4.1.2 on Linux and did not
see that error.
I will take a look and see if there is a simple fix to get around
this apparent compiler bug.
-Nathan
On Tue, 25 Jan 2011, Jeff Squyres wrote:
Short version
=
MTT turned up a problem with -std=gnu99 on OS X Leopard,
which ships with the gcc 4.0
compiler (OS X Snow Leopard ships with gcc 4.2, and doesn't
have a problem). Does anyone
have gcc 4.0 on Linux? I'm wondering if the same problem
would occur.
More details:
=
From our friends at Absoft:
-
The -std=gnu99 is causing the problem when used with gcc-4.0
( the default on Leopard with
Apple's XCode 3.1 development tools ):
BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s
conftest.s:2:3: error: invalid preprocessing directive
#_gsym_test_func
