Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] Bug-Report: visibility=hiden on Sparc/Sun CC
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2011-09-05 12:51:50

Le 04/09/2011 18:26, Igor Galić a écrit :
> Hi folks,
> first off: I would've submitted this Bug report via Trac if I could have
> done it anonymously. I *tried* to register, but the captcha was impossible
> to decipher -- And I can see! I strongly suggest you replace this with
> reCaptcha. It has an option to reload the captcha, and an audio option.
> Also: A complete reset of the form after a wrong attempt at the captcha
> makes for terrible user experience.
> These are things that will prevent you from getting bug reports.

Thanks for the feedback. Jeff, can you forward this to the admins? It
looks like there's a recaptcha plugin for trac.

> Now, for the "bug":
> I tried packaging hwloc for OpenCSW, building it with the default compiler
> which is Solaris Studio 12.2.
> I noticed a lot of errors of the kind:
> cc: Warning: illegal option -fvisibility=hidden
> So I canceled the compile and "fixed" that error with a simple
> perl -pi -e "s_at_-fvisibility=hidden_at_-xldscope=hidden_at_g"

I guess we should detect this at configure time.

> This worked out fine on amd64 and i386, but failed for sparc during
> a linking phase:
> CC lstopo-lstopo-xml.o
> CCLD lstopo
> Undefined first referenced
> symbol in file
> hwloc_insert_object_by_cpuset lstopo-lstopo-draw.o
> ld: fatal: Symbol referencing errors. No output written to .libs/lstopo
> I suspected this to be an issue of library ordering in the linking phase,
> something that GCC handles automatically by trying out different
> permutations. Testing it with GCC confirmed my hypothesis.
> Finally, I configured with --disable-visibility: That compiled and linked
> fine with Solaris CC on all platforms.

I don't see why disabling visibility would have solved/avoided the
library ordering issue. Any idea?

Could you try to find out which libraries/objects are actually given in
the wrong order? You can see the actual link command line by compiling
with "make V=1".