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

2012-09-13 Thread Brice Goglin 
Le 05/09/2012 17:42, Jeff Squyres a écrit :
> 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.
>

So we want to forbid $enable_plugins=yes -a $enable_shared=yes -a
$enable_static=yes ?

There's still one thing that I don't understand. What if you builds once
static, once shared, and install both as Samuel said above. Why don't we
have any problem there?

Brice

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

2012-09-06 Thread Samuel Thibault 
Jeff Squyres, le Thu 06 Sep 2012 15:46:29 +0200, a écrit :
> On Sep 6, 2012, at 7:46 AM, Jeff Squyres wrote:
> > (sorry; I forgot to ping Shiqing yesterday -- I just did so now to get a 
> > confirmation of what you found)
> 
> 
> Shiqing confirms that DSOs are disabled by default on Windows.  However, he 
> says that they do actually work if you enable them.

Mmm, I wonder how.  Actually now I remember, it wasn't darwin which was
posing problem with no -no-undefined, but windows, which requires it for
shared libraries, and thus requiring -lhwloc.

Samuel

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

2012-09-06 Thread Jeff Squyres 
On Sep 6, 2012, at 7:46 AM, Jeff Squyres wrote:

> (sorry; I forgot to ping Shiqing yesterday -- I just did so now to get a 
> confirmation of what you found)


Shiqing confirms that DSOs are disabled by default on Windows.  However, he 
says that they do actually work if you enable them.

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

2012-09-06 Thread Jeff Squyres 
On Sep 6, 2012, at 4:00 AM, Brice Goglin wrote:

> I just installed openmpi 1.6.1 win32.exe. I don't see any plugin in
> there. There are several libmpi*.dll or libo*.dll, but no mca_btl_* or so

Ah, ok.  

(sorry; I forgot to ping Shiqing yesterday -- I just did so now to get a 
confirmation of what you found)

> As long as we don't have libxml or libpci on Windows, hwloc plugins are
> useless on Windows. But that might change with other plugins.


Gotcha.

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

2012-09-06 Thread Brice Goglin 
Le 05/09/2012 18:05, Brice Goglin a écrit :
> Le 05/09/2012 17:23, Jeff Squyres a écrit :
>> On Sep 5, 2012, at 11:12 AM, Brice Goglin wrote:
>>
 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.
>> Ah, yes; I confess that I have not looked closely on the components branch.  
>> :-(
>>
>> But yes; you should not have --no-undefined when building the plugins.  It's 
>> fine for building libhwloc, I think.
> The reason for adding -no-undefined is "libtool: link: undefined symbols
> not allowed in i686-w64-ming32 shared libraries".
>
> There's an easy answer to this, disable plugins on Windows. Can you ask
> Shiqing about what he thinks/does for OMPI?
>

I just installed openmpi 1.6.1 win32.exe. I don't see any plugin in
there. There are several libmpi*.dll or libo*.dll, but no mca_btl_* or so

I don't see anything related to specialized networks (no openib or so),
so I guess there's no real need for plugins in OMPI/Windows.

As long as we don't have libxml or libpci on Windows, hwloc plugins are
useless on Windows. But that might change with other plugins.

Brice

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

2012-09-05 Thread 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] [hwloc-svn] svn:hwloc r4815 - branches/components/src

2012-09-05 Thread 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] [hwloc-svn] svn:hwloc r4815 - branches/components/src

2012-09-05 Thread 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] [hwloc-svn] svn:hwloc r4815 - branches/components/src

2012-09-05 Thread 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

2012-09-05 Thread 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

2012-09-05 Thread 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

2012-09-05 Thread 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/