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
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/
