This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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 */
>> -#define HWLOC_C_HAVE_VISIBILITY 1
>> +#define HWLOC_C_HAVE_VISIBILITY 0
> 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.
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