Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

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.

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


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.

-Paul

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