Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Jeff Squyres]

On Sep 5, 2012, at 11:36 AM, Samuel Thibault wrote:

>> 1. We do not allow "./configure --enable-static --enable-shared".  Even 
>> though that's valid Automake/Libtool (i.e., it'll generate libhwloc.a *and* 
>> libhwloc.so), we don't allow it.
> 
> Well, actually for instance Debian builds once with -static, and once
> with -shared, and installs both...

That scenario is fine.  It's just the "build both at once" scenario that isn't 
allowed.

> BTW, I guess it wasn't attempted to make OMPI plugins work on windows?
> The nightmare is even worse there...

I don't know if Shiqing (the main OMPI Windows maintainer) allows plugins on 
Windows, or if he slurps the plugins into libmpi.dll.

>> 2. If --enable-shared (which is OMPI's default), we build plugins as DSOs 
>> and do not link them against libmpi.so (and friends).
>> 
>> 3. If --enable-static, we build plugins are part of libmpi.a (and friends).  
>> Issues #9 and #12 from table 1 on the wiki are avoided, as are 
>> 
>> 4. However: in both libmpi.so / libmpi.a cases, we can still allow the use 
>> of DSOs -- e.g., if a vendor drops in another DSO plugin that OMPI will just 
>> find/load/use at run time.  This is cases #2, #5, #8, and #11 in table 1.
> 
> Don't these vendor-provided DSO need to use some OMPI functions?

Yes.  And they work fine for #2 (above).

> That said it looks a not too bad solution: avoiding loading plugins in
> the static case, but still allowing third-party plugins, and it's up to
> the user to make it work :)


That's generally the conclusion we came to.  The "need to open (hwloc|OMPI) as 
a plugin itself" case is not common.  Specifically, it came up in the case of 
Python, Perl, and R MPI bindings.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] -lhwloc in components.

[Jeff Squyres]

I agree -- all of the things you mention are do-able.

But it's a whole lot more bookkeeping and care/feeding to ensure that nothing 
goes wrong vs. just calling a hwloc core function and assuming it's there.  
Such things will require maintenance over time.

In the end -- it's a tradeoff:

- do we want the maintenance associated with a struct full of core function 
pointers?

or

- do we want to use the solution I mentioned in 
http://www.open-mpi.org/community/lists/hwloc-devel/2012/09/3253.php?

Both have strengths / weaknesses.



On Sep 5, 2012, at 11:25 AM, Samuel Thibault wrote:

> Jeff Squyres, le Wed 05 Sep 2012 17:13:56 +0200, a écrit :
>>> The source code shouldn't need to be modified:
>>> 
>>> #define hwloc_foo_bar(arg1, arg2) hwloc_funcs->foo_bar(arg1, arg2)
>> 
>> You need to make sure that #define is only effected in certain places in the 
>> code.
> 
> Well, all the places that will constitute a plugin, no?
> 
>> And you need to ensure that hwloc_funcs->[foo] isn't attempted to be used 
>> before it has been filled in.
> 
> As I said in my earlier mail, hwloc_funcs would be provided by the
> loader of the plugin, so it can make sure it's filled in (I forgot to
> mention that what I call hwloc_funcs above is an internal variable of
> the plugin, not a symbol provided by libhwloc.so).
> 
>> And unless there is a very fixed set of functions that can be called by 
>> plugins,
> 
> Well, I believe we'll have to have that anyway. That was part of the
> whole discussion about plugins a long time ago.
> 
>> you'll probably need to grow hwloc_funcs over time, which may lead to ABI 
>> issues...?
> 
> Sure.  We can for instance make the plugin check for the size of
> hwloc_funcs provided by the plugin loader vs the size that it was
> compiled against, and thus refuse to get loaded by an older hwloc.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Jeff Squyres]

On Sep 5, 2012, at 11:19 AM, Samuel Thibault wrote:

>> Undefined symbols at .so-creation time are allowed on all platforms (even OS 
>> X).
> 
> Even OS X?  I thought I had seen such issue on OS X, precisely.

Yep.

>> But they must be resolved at load time.
> 
> Or not, when resolving lazily :)


Good point.  I don't remember exactly what the rules are here, and they may 
vary from OS to OS (i.e., some OS's may not support lazy symbol resolution...?).

But it's easiest/safest to think of it in terms of: the symbols must be able to 
be resolved when this .so is dlopen'ed.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] -lhwloc in components.

[Jeff Squyres]

On Sep 5, 2012, at 11:08 AM, Samuel Thibault wrote:

>> No.  It's not really an ltdl issue.  ltdl is just a portable wrapper around 
>> OS-specific dlopen-like mechanisms.  
> 
> I understand that, but dlopen is usually used for plugins, and plugins
> usually need such kind of calling back into what loaded the plugin.

Sure.  It's really a matter of the linker scopes. 

IIRC, in a somewhat-recent version of ltdl (I don't remember the version 
offhand -- perhaps somewhere in the 2.2 series?), they changed the default of 
lt_dlopen to start opening plugins in private scopes, not the global scope.  
That's what has contributed to this hubaloo -- by default, plugins can no 
longer see the global scope, which is typically where the symbols are that they 
need to resolve (e.g., in the libhwloc.so that is linked in to lstopo).

>>> One way would be to pass to the component a structure with all the
>>> useful function pointers (using #define to keep the same source code).
>> 
>> We thought about this in OMPI and decided it would be a nightmare in the 
>> source code.
> 
> The source code shouldn't need to be modified:
> 
> #define hwloc_foo_bar(arg1, arg2) hwloc_funcs->foo_bar(arg1, arg2)


You need to make sure that #define is only effected in certain places in the 
code.  And you need to ensure that hwloc_funcs->[foo] isn't attempted to be 
used before it has been filled in.  And unless there is a very fixed set of 
functions that can be called by plugins, you'll probably need to grow 
hwloc_funcs over time, which may lead to ABI issues...?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Brice Goglin]

Le 05/09/2012 17:08, Jeff Squyres a écrit :
> On Sep 5, 2012, at 10:23 AM, Samuel Thibault wrote:
>
>>> The problem I was trying to fix below is that linking hwloc plugins on
>>> Darwin failed because plugins referred to hwloc-core symbols. Nothing on
>>> the libtool command-line said where to find those symbols (I don't
>>> understand why it worked on other platforms).
>> Because on other platforms, undefined symbols are allowed.
> Undefined symbols at .so-creation time are allowed on all platforms (even OS 
> X).  But they must be resolved at load time.
>
> To be clear: we have exactly the same situation in OMPI, and we do not link 
> any of our DSOs against libmpi.so (we used to, but we don't any more because 
> of the discussion on the https://svn.open-mpi.org/trac/ompi/wiki/Linkers wiki 
> page).  
>

So I would need to remove -no-undefined from plugins ldflags and darwin
(and you?) may be happy again? But iirc, removing this flag broke
something else, I'll check again.

By the way, we have almost no internal state in hwloc.

Brice

Re: [hwloc-devel] -lhwloc in components.

[Samuel Thibault]

Jeff Squyres, le Wed 05 Sep 2012 17:06:00 +0200, a écrit :
> On Sep 5, 2012, at 10:21 AM, Samuel Thibault wrote:
> 
> > So ltdl does not help for that matter?
> 
> No.  It's not really an ltdl issue.  ltdl is just a portable wrapper around 
> OS-specific dlopen-like mechanisms.  

I understand that, but dlopen is usually used for plugins, and plugins
usually need such kind of calling back into what loaded the plugin.

> > One way would be to pass to the component a structure with all the
> > useful function pointers (using #define to keep the same source code).
> 
> We thought about this in OMPI and decided it would be a nightmare in the 
> source code.

The source code shouldn't need to be modified:

#define hwloc_foo_bar(arg1, arg2) hwloc_funcs->foo_bar(arg1, arg2)

Samuel

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Jeff Squyres]

On Sep 5, 2012, at 10:13 AM, Brice Goglin wrote:

> I understand pretty much nothing in your mails :)

Don't linkers suck?  :-)  That wiki page is the result of much hard-won 
knowledge.

> The problem I was trying to fix below is that linking hwloc plugins on
> Darwin failed because plugins referred to hwloc-core symbols.

That should be fine, as long as you are dlopening the plugins in the same scope 
as the main application.  Then the unresolved symbols in the plugins should be 
resolved against the libhwloc.so that is already loaded in the process space.

That's what lt_dladvise() is for.

> Nothing on
> the libtool command-line said where to find those symbols (I don't
> understand why it worked on other platforms).

Correct.  This is more of a run-time issue than a compile/link-time issue 
(discounting -rpath, for the moment).

To clarify: it's fine to build any kind of shared library (DSO or otherwise) 
with unresolved symbols.  They just need to be resolved when that shared 
library is loaded -- either by symbols that are already in the process space or 
by some dependent library that also gets loaded at the same time.

> I added -lhwloc as a way to tell the linker "those symbols are there". I
> didn't think it would statically link libhwloc inside the plugins, and
> it doesn't seem to do so (from what I see in objdump). Is this what you
> mean?

Yes and no.

If libhwloc is libhowloc.a, then yes, it will statically link those symbols in 
the DSOs.  If libhwloc is libhwloc.so, then you're probably ok -- this is case 
#1 (and footnote (*1*)) on table 1.  Specifically:

(*1*) As far as we know, this works on all platforms that have dlopen (i.e., 
almost everywhere). But we've only tested (recently) Linux, OSX, and Solaris. 
These 3 dynamic loaders are smart enough to realize that they only need to load 
libmpi.so once (i.e., that the implicit dependency of libmpi.so brought in by 
the components is the same libmpi.so that is already loaded), so everything 
works fine.

> It's really a problem when linking, not about loading (and scopes that I
> don't know anything about), but I couldn't test loading before linking
> worked.

No.  It actually is a problem with loading -- not linking.  :-)

> Anyway, how should I solve this?

Let me answer Samuel's mails and come back to this question...

> Brice
> 
> 
> 
> Le 05/09/2012 15:58, Jeff Squyres a écrit :
>> I should clarify...
>> 
>> In OMPI, if we're building libmpi.so, we default to building plugins as 
>> DSOs.  If we're building libmpi.a, then we slurp all the plugins into 
>> libmpi.a (i.e., don't build them as DSOs).  This avoids many of the issues 
>> in table 2.
>> 
>> 
>> On Sep 5, 2012, at 9:54 AM, Jeff Squyres wrote:
>> 
>>> This is a bad idea.
>>> 
>>> I'm trying to remember the reason why, but we explicitly *removed* such -l 
>>> statements (e.g., removed "-lmpi" from the plugins).  Hmm...  Oh, right.  
>>> Every time I think I understand linkers, I find out that I don't.  So last 
>>> time we had a Big Confusion Discussion About Linkers (BCDAL), I wrote it 
>>> all up:
>>> 
>>>   https://svn.open-mpi.org/trac/ompi/wiki/Linkers
>>> 
>>> The 4th column in these tables is labeled "OMPI DSO components depend on 
>>> libmpi.so?" (which is somewhat of a misnomer, because not all components 
>>> are at the MPI layer -- so consider it to mean "OMPI DSO components depend 
>>> on some OMPI library, such as libmpi.so?")
>>> 
>>> The problem cases are #9 and #12 in the first table: i.e., static linking.
>>> 
>>> Instead, we use lt_dladvise() to open hwloc plugins in the same scope as 
>>> the main application.
>>> 
>>> Of course, this has its own tradeoffs -- if hwloc itself, is opened as a 
>>> plugin in a private scope, then the plugins won't be able to find the 
>>> symbols it needs (i.e., cases #14, #15, #17, #18, #20, #21, #23, and #24 in 
>>> the 2nd table). 
>>> 
>>> Until POSIX effects hierarchical linker scopes (or at least something like 
>>> "please dlopen this plugin and put it in XYZ linker scope"), there's really 
>>> no good solution here.  :-(
>>> 
>>> 
>>> 
>>> On Sep 5, 2012, at 6:03 AM,  wrote:
>>> 
 Author: bgoglin (Brice Goglin)
 Date: 2012-09-05 06:03:52 EDT (Wed, 05 Sep 2012)
 New Revision: 4815
 URL: https://svn.open-mpi.org/trac/hwloc/changeset/4815
 
 Log:
 Pass -lhwloc to all plugins, at least Darwin wants it
 (plugins use some hwloc functions)
 
 Define a plugins_ldflags with all common stuff for plugins
 (this somehow reverts r4811)
 
 Text files modified: 
 branches/components/src/Makefile.am |13 +++--  
  
 1 files changed, 7 insertions(+), 6 deletions(-)
 
 Modified: branches/components/src/Makefile.am
 ==
 --- branches/components/src/Makefile.amWed Sep  5 06:03:36 2012
 (r4814)
 +++ 

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Samuel Thibault]

Brice Goglin, le Wed 05 Sep 2012 16:13:31 +0200, a écrit :
> The problem I was trying to fix below is that linking hwloc plugins on
> Darwin failed because plugins referred to hwloc-core symbols. Nothing on
> the libtool command-line said where to find those symbols (I don't
> understand why it worked on other platforms).

Because on other platforms, undefined symbols are allowed.

> I added -lhwloc as a way to tell the linker "those symbols are there".
> I didn't think it would statically link libhwloc inside the plugins,
> and it doesn't seem to do so (from what I see in objdump). Is this
> what you mean?

No, he means that it'll also make the loader load libhwloc.so. Even if
the application linked libhwloc.a statically.

> It's really a problem when linking, not about loading

But it has effects on loading.

Samuel

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Jeff Squyres]

I should clarify...

In OMPI, if we're building libmpi.so, we default to building plugins as DSOs.  
If we're building libmpi.a, then we slurp all the plugins into libmpi.a (i.e., 
don't build them as DSOs).  This avoids many of the issues in table 2.


On Sep 5, 2012, at 9:54 AM, Jeff Squyres wrote:

> This is a bad idea.
> 
> I'm trying to remember the reason why, but we explicitly *removed* such -l 
> statements (e.g., removed "-lmpi" from the plugins).  Hmm...  Oh, right.  
> Every time I think I understand linkers, I find out that I don't.  So last 
> time we had a Big Confusion Discussion About Linkers (BCDAL), I wrote it all 
> up:
> 
>https://svn.open-mpi.org/trac/ompi/wiki/Linkers
> 
> The 4th column in these tables is labeled "OMPI DSO components depend on 
> libmpi.so?" (which is somewhat of a misnomer, because not all components are 
> at the MPI layer -- so consider it to mean "OMPI DSO components depend on 
> some OMPI library, such as libmpi.so?")
> 
> The problem cases are #9 and #12 in the first table: i.e., static linking.
> 
> Instead, we use lt_dladvise() to open hwloc plugins in the same scope as the 
> main application.
> 
> Of course, this has its own tradeoffs -- if hwloc itself, is opened as a 
> plugin in a private scope, then the plugins won't be able to find the symbols 
> it needs (i.e., cases #14, #15, #17, #18, #20, #21, #23, and #24 in the 2nd 
> table). 
> 
> Until POSIX effects hierarchical linker scopes (or at least something like 
> "please dlopen this plugin and put it in XYZ linker scope"), there's really 
> no good solution here.  :-(
> 
> 
> 
> On Sep 5, 2012, at 6:03 AM,  wrote:
> 
>> Author: bgoglin (Brice Goglin)
>> Date: 2012-09-05 06:03:52 EDT (Wed, 05 Sep 2012)
>> New Revision: 4815
>> URL: https://svn.open-mpi.org/trac/hwloc/changeset/4815
>> 
>> Log:
>> Pass -lhwloc to all plugins, at least Darwin wants it
>> (plugins use some hwloc functions)
>> 
>> Define a plugins_ldflags with all common stuff for plugins
>> (this somehow reverts r4811)
>> 
>> Text files modified: 
>>  branches/components/src/Makefile.am |13 +++--   
>> 
>>  1 files changed, 7 insertions(+), 6 deletions(-)
>> 
>> Modified: branches/components/src/Makefile.am
>> ==
>> --- branches/components/src/Makefile.am  Wed Sep  5 06:03:36 2012
>> (r4814)
>> +++ branches/components/src/Makefile.am  2012-09-05 06:03:52 EDT (Wed, 
>> 05 Sep 2012)  (r4815)
>> @@ -21,6 +21,7 @@
>> 
>> pluginsdir = $(libdir)/hwloc
>> plugins_LTLIBRARIES = 
>> +plugins_ldflags = -module -avoid-version -lhwloc
>> AM_CPPFLAGS += -DHWLOC_PLUGINS_DIR=\"$(pluginsdir)\"
>> 
>> # Sources and ldflags
>> @@ -40,7 +41,6 @@
>>topology-xml.c \
>>topology-xml-nolibxml.c
>> ldflags =
>> -common_ldflags = 
>> 
>> # Conditionally add to the sources and ldflags
>> 
>> @@ -52,7 +52,7 @@
>> xml_libxml_la_SOURCES = topology-xml-libxml.c
>> xml_libxml_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
>> xml_libxml_la_CFLAGS = $(AM_CFLAGS) $(HWLOC_LIBXML2_CFLAGS)
>> -xml_libxml_la_LDFLAGS = $(common_ldflags) -module -avoid-version 
>> $(HWLOC_LIBXML2_LIBS)
>> +xml_libxml_la_LDFLAGS = $(plugins_ldflags) $(HWLOC_LIBXML2_LIBS)
>> endif
>> endif HWLOC_HAVE_LIBXML2
>> 
>> @@ -64,7 +64,7 @@
>> core_libpci_la_SOURCES = topology-libpci.c
>> core_libpci_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
>> core_libpci_la_CFLAGS = $(AM_CFLAGS) $(HWLOC_PCI_CFLAGS)
>> -core_libpci_la_LDFLAGS = $(common_ldflags) -module -avoid-version 
>> $(HWLOC_PCI_LIBS)
>> +core_libpci_la_LDFLAGS = $(plugins_ldflags) $(HWLOC_PCI_LIBS)
>> endif
>> endif HWLOC_HAVE_LIBPCI
>> 
>> @@ -105,7 +105,8 @@
>> endif HWLOC_HAVE_FREEBSD
>> 
>> if HWLOC_HAVE_GCC
>> -common_ldflags += -no-undefined
>> +ldflags += -no-undefined
>> +plugins_ldflags += -no-undefined
>> endif HWLOC_HAVE_GCC
>> 
>> if HWLOC_HAVE_WINDOWS
>> @@ -136,7 +137,7 @@
>> # Installable library
>> 
>> libhwloc_la_SOURCES = $(sources)
>> -libhwloc_la_LDFLAGS = $(common_ldflags) $(ldflags) -version-info 
>> $(libhwloc_so_version) $(HWLOC_LIBS)
>> +libhwloc_la_LDFLAGS = $(ldflags) -version-info $(libhwloc_so_version) 
>> $(HWLOC_LIBS)
>> 
>> if HWLOC_HAVE_PLUGINS
>> AM_CPPFLAGS += $(LTDLINCL)
>> @@ -168,5 +169,5 @@
>> check_LTLIBRARIES = core_fake.la
>> core_fake_la_SOURCES = topology-fake.c
>> core_fake_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
>> -core_fake_la_LDFLAGS = $(common_ldflags) -module -avoid-version -rpath 
>> /nowhere # force libtool to build a shared-library even it's check-only
>> +core_fake_la_LDFLAGS = $(plugins_ldflags) -rpath /nowhere # force libtool 
>> to build a shared-library even it's check-only
>> endif
>> ___
>> hwloc-svn mailing list
>> hwloc-...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

[Jeff Squyres]

This is a bad idea.

I'm trying to remember the reason why, but we explicitly *removed* such -l 
statements (e.g., removed "-lmpi" from the plugins).  Hmm...  Oh, right.  Every 
time I think I understand linkers, I find out that I don't.  So last time we 
had a Big Confusion Discussion About Linkers (BCDAL), I wrote it all up:

https://svn.open-mpi.org/trac/ompi/wiki/Linkers

The 4th column in these tables is labeled "OMPI DSO components depend on 
libmpi.so?" (which is somewhat of a misnomer, because not all components are at 
the MPI layer -- so consider it to mean "OMPI DSO components depend on some 
OMPI library, such as libmpi.so?")

The problem cases are #9 and #12 in the first table: i.e., static linking.

Instead, we use lt_dladvise() to open hwloc plugins in the same scope as the 
main application.

Of course, this has its own tradeoffs -- if hwloc itself, is opened as a plugin 
in a private scope, then the plugins won't be able to find the symbols it needs 
(i.e., cases #14, #15, #17, #18, #20, #21, #23, and #24 in the 2nd table). 

Until POSIX effects hierarchical linker scopes (or at least something like 
"please dlopen this plugin and put it in XYZ linker scope"), there's really no 
good solution here.  :-(



On Sep 5, 2012, at 6:03 AM,  wrote:

> Author: bgoglin (Brice Goglin)
> Date: 2012-09-05 06:03:52 EDT (Wed, 05 Sep 2012)
> New Revision: 4815
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/4815
> 
> Log:
> Pass -lhwloc to all plugins, at least Darwin wants it
> (plugins use some hwloc functions)
> 
> Define a plugins_ldflags with all common stuff for plugins
> (this somehow reverts r4811)
> 
> Text files modified: 
>   branches/components/src/Makefile.am |13 +++--   
> 
>   1 files changed, 7 insertions(+), 6 deletions(-)
> 
> Modified: branches/components/src/Makefile.am
> ==
> --- branches/components/src/Makefile.am   Wed Sep  5 06:03:36 2012
> (r4814)
> +++ branches/components/src/Makefile.am   2012-09-05 06:03:52 EDT (Wed, 
> 05 Sep 2012)  (r4815)
> @@ -21,6 +21,7 @@
> 
> pluginsdir = $(libdir)/hwloc
> plugins_LTLIBRARIES = 
> +plugins_ldflags = -module -avoid-version -lhwloc
> AM_CPPFLAGS += -DHWLOC_PLUGINS_DIR=\"$(pluginsdir)\"
> 
> # Sources and ldflags
> @@ -40,7 +41,6 @@
> topology-xml.c \
> topology-xml-nolibxml.c
> ldflags =
> -common_ldflags = 
> 
> # Conditionally add to the sources and ldflags
> 
> @@ -52,7 +52,7 @@
> xml_libxml_la_SOURCES = topology-xml-libxml.c
> xml_libxml_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
> xml_libxml_la_CFLAGS = $(AM_CFLAGS) $(HWLOC_LIBXML2_CFLAGS)
> -xml_libxml_la_LDFLAGS = $(common_ldflags) -module -avoid-version 
> $(HWLOC_LIBXML2_LIBS)
> +xml_libxml_la_LDFLAGS = $(plugins_ldflags) $(HWLOC_LIBXML2_LIBS)
> endif
> endif HWLOC_HAVE_LIBXML2
> 
> @@ -64,7 +64,7 @@
> core_libpci_la_SOURCES = topology-libpci.c
> core_libpci_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
> core_libpci_la_CFLAGS = $(AM_CFLAGS) $(HWLOC_PCI_CFLAGS)
> -core_libpci_la_LDFLAGS = $(common_ldflags) -module -avoid-version 
> $(HWLOC_PCI_LIBS)
> +core_libpci_la_LDFLAGS = $(plugins_ldflags) $(HWLOC_PCI_LIBS)
> endif
> endif HWLOC_HAVE_LIBPCI
> 
> @@ -105,7 +105,8 @@
> endif HWLOC_HAVE_FREEBSD
> 
> if HWLOC_HAVE_GCC
> -common_ldflags += -no-undefined
> +ldflags += -no-undefined
> +plugins_ldflags += -no-undefined
> endif HWLOC_HAVE_GCC
> 
> if HWLOC_HAVE_WINDOWS
> @@ -136,7 +137,7 @@
> # Installable library
> 
> libhwloc_la_SOURCES = $(sources)
> -libhwloc_la_LDFLAGS = $(common_ldflags) $(ldflags) -version-info 
> $(libhwloc_so_version) $(HWLOC_LIBS)
> +libhwloc_la_LDFLAGS = $(ldflags) -version-info $(libhwloc_so_version) 
> $(HWLOC_LIBS)
> 
> if HWLOC_HAVE_PLUGINS
> AM_CPPFLAGS += $(LTDLINCL)
> @@ -168,5 +169,5 @@
> check_LTLIBRARIES = core_fake.la
> core_fake_la_SOURCES = topology-fake.c
> core_fake_la_CPPFLAGS = $(AM_CPPFLAGS) -DHWLOC_BUILD_PLUGIN
> -core_fake_la_LDFLAGS = $(common_ldflags) -module -avoid-version -rpath 
> /nowhere # force libtool to build a shared-library even it's check-only
> +core_fake_la_LDFLAGS = $(plugins_ldflags) -rpath /nowhere # force libtool to 
> build a shared-library even it's check-only
> endif
> ___
> hwloc-svn mailing list
> hwloc-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/