Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] 1.3.2rc1 failures w/ icc on x86 (visibility?)
From: Paul H. Hargrove (PHHargrove_at_[hidden])
Date: 2012-02-10 14:04:54

On 2/10/2012 9:27 AM, Paul H. Hargrove wrote:
> I have versions 8.1.032, 9.0.024 and 9.1.042 of the Intel compilers on
> a Linux/x86 (32-bit) host.
> All three can configure and build hwloc-1.3.2rc1, but all are failing
> "make check" in the same way.
> What I see is ton(ne)s of linker messages and every executable SEGVs.
> The linker messages look like:
>> CC hwloc_synthetic.o
>> CCLD hwloc_synthetic
>> ld: hwloc_synthetic.o(.text+0x1c): unresolvable relocation against
>> symbol `hwloc_topology_init'
>> ld: hwloc_synthetic.o(.text+0x2a): unresolvable relocation against
>> symbol `hwloc_topology_set_synthetic'
>> ld: hwloc_synthetic.o(.text+0x33): unresolvable relocation against
>> symbol `hwloc_topology_load'
>> ld: hwloc_synthetic.o(.text+0x3c): unresolvable relocation against
>> symbol `hwloc_topology_check'
>> ld: hwloc_synthetic.o(.text+0x46): unresolvable relocation against
>> symbol `hwloc_topology_get_depth'
>> ld: hwloc_synthetic.o(.text+0x64): unresolvable relocation against
>> symbol `hwloc_get_nbobjs_by_depth'
>> ld: hwloc_synthetic.o(.text+0x8a): unresolvable relocation against
>> symbol `hwloc_get_obj_by_depth'
>> ld: hwloc_synthetic.o(.text+0xc6): unresolvable relocation against
>> symbol `hwloc_topology_destroy'
> Where most tests have far more of these.
> For the moment, I am going to assume the SEGVs are a result of the
> linker problems.
> As compared to gcc on the same system, the only difference in
> include/private/autogen/config.h is:
>> /* Whether C compiler supports symbol visibility or not */
> Where the '1' is the build with the Intel compiler.
> So, my current suspicion falls on the visibility crud.
> I can confirm that "HWLOC_CFLAGS = -fvisibility=hidden" in Makefile.
> Other then that, I don't know where to begin looking at this problem.
> -Paul

For comparison, tried building the OMPI 1.4.5rc5 with these Intel compilers.
icc-9.1.042: caused assertion failure in ld - let not consider this one
icc-9.0.024: PASSed "make all install check clean"
icc-8.1.032: PASSed "make all install check clean"

So, I believe that the two PASS results shows that the correct
visibility logic is "known" in ompi.
The key difference appears to be that ompi has decided NOT to use
-fvisibility with these compilers:
> ============================================================================
> == Symbol Visibility Feature
> ============================================================================
> checking if icc supports -fvisibility... no
> checking enable symbol visibility... no
And from the ompi-1.4.5rc5 config.log:
> configure:164594: checking if icc supports -fvisibility
> configure:164624: icc -o conftest -O3 -DNDEBUG -finline-functions
> -fno-strict-aliasing -restrict -pthread -fvisibility=hidden
> conftest.c -lnsl -lutil >&5
> /tmp/iccFBKDBg.o: In function `bar':
> conftest.c:(.text+0x26): undefined reference to `fputs'
> ld: conftest: hidden symbol `fputs' isn't defined
> ld: final link failed: Nonrepresentable section on output
> configure:164631: $? = 1

As compared to hwloc-1.3.2rc1:
> configure:8253: checking if icc supports -fvisibility
> configure:8268: icc -o conftest -fvisibility=hidden -Werror
> conftest.c >&5
> configure:8268: $? = 0
> configure:8279: result: yes

So, my educated guess is that one needs to (back)port the configure
logic for visibility support.


Paul H. Hargrove                          PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department                   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900