Re: [OMPI devel] [OMPI users] Adding a new BTL

[Jeff Squyres (jsquyres)]

+1 on what George says.

If you look at various components around Open MPI, many component and/or module 
functions *are* actually static because they aren't needed outside that .c file 
in the component.  It just depends on the individual component code base.


> On Feb 25, 2016, at 8:48 PM, George Bosilca  wrote:
> 
> Durga,
> 
> If we declare these functions as static we are forced to have the functions 
> defined and used in the same source file. The fact that they are declared as 
> extern allows us to use these functions in all files in the same component. 
> Once linked in the corresponding shared library, all symbols not marked with 
> OPAL_DECLSPEC will not be visible, forcing all interactions with the 
> component to go through the component structure (mca_btl_template_module_t 
> mca_btl_template_module) which is the only visible symbol.
> 
>   George.
> 
> 
> On Thu, Feb 25, 2016 at 7:41 PM, dpchoudh .  wrote:
> Hello Gilles
> 
> Thank you; the build is successful now.
> 
> I do have a generic, unrelated question, though:
> 
> I really appreciate how all the principle of object oriented design 
> principles have been used in OMPI architecture and have been implemented in a 
> language that is not object oriented. It is a textbook example in software 
> engineering.
> 
> However, I see that functions that are indirectly referenced, via a structure 
> of function pointers, have been declared 'extern' in header files. This, to 
> me, looks like against the principle of code design. Making these 'static' 
> and removing them from the headers does not break the build of course, and 
> does not even generate warnings. As an example, the following functions need 
> not be externalized, except, perhaps, for debugging:
> 
> mca_btl_template_module_t mca_btl_template_module = {
> .super = {
> .btl_component = _btl_template_component.super,
> .btl_add_procs = mca_btl_template_add_procs,
> .btl_del_procs = mca_btl_template_del_procs,
> .btl_register = mca_btl_template_register,
> .btl_finalize = mca_btl_template_finalize,
> .btl_alloc = mca_btl_template_alloc,
> .btl_free = mca_btl_template_free,
> .btl_prepare_src = mca_btl_template_prepare_src,
> .btl_send = mca_btl_template_send,
> .btl_put = mca_btl_template_put,
> .btl_get = mca_btl_template_get,
> .btl_register_mem = mca_btl_template_register_mem,
> .btl_deregister_mem = mca_btl_template_deregister_mem,
> .btl_ft_event = mca_btl_template_ft_event
> }
> };
> 
> Is there any reason why it is done this way? If I made them 'static' in my 
> own BTL code, would I get into trouble down the road?
> 
> Thanks
> Durga
> 
> 
> 
> Life is complex. It has real and imaginary parts.
> 
> On Thu, Feb 25, 2016 at 7:02 PM, Gilles Gouaillardet 
>  wrote:
> on master/v2.x, you also have to
> 
> rm -f opal/mca/btl/lf/.opal_ignore
> 
> (and this file would have been .ompi_ignore on v1.10)
> 
> Cheers,
> 
> Gilles
> 
> On Fri, Feb 26, 2016 at 7:44 AM, dpchoudh .  wrote:
> > Hello Jeff and other developers:
> >
> > Attached are five files:
> > 1-2: Full output from autogen.pl and configure, captured with: ./ 2>&1
> > | tee .log
> > 3. Makefile.am of the specific BTL directory
> > 4. configure.m4 of the same directory
> > 5. config.log, as generated internally by autotools
> >
> > Thank you
> > Durga
> >
> >
> > Life is complex. It has real and imaginary parts.
> >
> > On Thu, Feb 25, 2016 at 5:15 PM, Jeff Squyres (jsquyres)
> >  wrote:
> >>
> >> Can you send the full output from autogen and configure?
> >>
> >> Also, this is probably better suited for the Devel list, since we're
> >> talking about OMPI internals.
> >>
> >> Sent from my phone. No type good.
> >>
> >> On Feb 25, 2016, at 2:06 PM, dpchoudh .  wrote:
> >>
> >> Hello Gilles
> >>
> >> Thank you very much for your advice. Yes, I copied the templates from the
> >> master branch to the 1.10.2 release, since the release does not have them.
> >> And yes, changing the Makefile.am as you suggest did make the autogen error
> >> go away.
> >>
> >> However, in the master branch, the autotools seem to be ignoring the new
> >> btl directory altogether; i.e. I do not get a Makefile.in from the
> >> Makefile.am.
> >>
> >> In the 1.10.2 release, doing an identical sequence of steps do create a
> >> Makefile.in from Makefile.am (via autogen) and a Makefile from Makefile.in
> >> (via configure), but of course, the new BTL does not build because the
> >> include paths in master and 1.10.2 are different.
> >>
> >> My Makefile.am and configure.m4 are as follows. Any thoughts on what it
> >> would take in the master branch to hook up the new BTL directory?
> >>
> >> opal/mca/btl/lf/configure.m4
> >> # 
> >> 

Re: [OMPI devel] [OMPI users] Adding a new BTL

[Jeff Squyres (jsquyres)]

On Feb 25, 2016, at 7:02 PM, Gilles Gouaillardet 
 wrote:
> 
> on master/v2.x, you also have to
> 
> rm -f opal/mca/btl/lf/.opal_ignore

Gilles is exactly right.  It's a bit buried in the autogen output, but you can 
see this:

--- Found opal / btl / lf component
=> Ignored (found .opal_ignore file)

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

[hwloc-devel] Create success (hwloc git 1.11.2-34-gc05bc6e)

[MPI Team]

Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc 1.11.2-34-gc05bc6e
Start time: Thu Feb 25 21:03:15 EST 2016
End time:   Thu Feb 25 21:04:49 EST 2016

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc git dev-1014-g877203d)

[MPI Team]

Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc dev-1014-g877203d
Start time: Thu Feb 25 21:01:02 EST 2016
End time:   Thu Feb 25 21:02:57 EST 2016

Your friendly daemon,
Cyrador

Re: [OMPI devel] [OMPI users] Adding a new BTL

[George Bosilca]

Durga,

If we declare these functions as static we are forced to have the functions
defined and used in the same source file. The fact that they are declared
as extern allows us to use these functions in all files in the same
component. Once linked in the corresponding shared library, all symbols not
marked with OPAL_DECLSPEC will not be visible, forcing all interactions
with the component to go through the component structure
(mca_btl_template_module_t
mca_btl_template_module) which is the only visible symbol.

  George.


On Thu, Feb 25, 2016 at 7:41 PM, dpchoudh .  wrote:

> Hello Gilles
>
> Thank you; the build is successful now.
>
> I do have a generic, unrelated question, though:
>
> I really appreciate how all the principle of object oriented design
> principles have been used in OMPI architecture and have been implemented in
> a language that is not object oriented. It is a textbook example in
> software engineering.
>
> However, I see that functions that are indirectly referenced, via a
> structure of function pointers, have been declared 'extern' in header
> files. This, to me, looks like against the principle of code design. Making
> these 'static' and removing them from the headers does not break the build
> of course, and does not even generate warnings. As an example, the
> following functions need not be externalized, except, perhaps, for
> debugging:
>
> mca_btl_template_module_t mca_btl_template_module = {
> .super = {
> .btl_component = _btl_template_component.super,
> .btl_add_procs = mca_btl_template_add_procs,
> .btl_del_procs = mca_btl_template_del_procs,
> .btl_register = mca_btl_template_register,
> .btl_finalize = mca_btl_template_finalize,
> .btl_alloc = mca_btl_template_alloc,
> .btl_free = mca_btl_template_free,
> .btl_prepare_src = mca_btl_template_prepare_src,
> .btl_send = mca_btl_template_send,
> .btl_put = mca_btl_template_put,
> .btl_get = mca_btl_template_get,
> .btl_register_mem = mca_btl_template_register_mem,
> .btl_deregister_mem = mca_btl_template_deregister_mem,
> .btl_ft_event = mca_btl_template_ft_event
> }
> };
>
> Is there any reason why it is done this way? If I made them 'static' in my
> own BTL code, would I get into trouble down the road?
>
> Thanks
> Durga
>
>
>
> Life is complex. It has real and imaginary parts.
>
> On Thu, Feb 25, 2016 at 7:02 PM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
>
>> on master/v2.x, you also have to
>>
>> rm -f opal/mca/btl/lf/.opal_ignore
>>
>> (and this file would have been .ompi_ignore on v1.10)
>>
>> Cheers,
>>
>> Gilles
>>
>> On Fri, Feb 26, 2016 at 7:44 AM, dpchoudh .  wrote:
>> > Hello Jeff and other developers:
>> >
>> > Attached are five files:
>> > 1-2: Full output from autogen.pl and configure, captured with: ./
>> 2>&1
>> > | tee .log
>> > 3. Makefile.am of the specific BTL directory
>> > 4. configure.m4 of the same directory
>> > 5. config.log, as generated internally by autotools
>> >
>> > Thank you
>> > Durga
>> >
>> >
>> > Life is complex. It has real and imaginary parts.
>> >
>> > On Thu, Feb 25, 2016 at 5:15 PM, Jeff Squyres (jsquyres)
>> >  wrote:
>> >>
>> >> Can you send the full output from autogen and configure?
>> >>
>> >> Also, this is probably better suited for the Devel list, since we're
>> >> talking about OMPI internals.
>> >>
>> >> Sent from my phone. No type good.
>> >>
>> >> On Feb 25, 2016, at 2:06 PM, dpchoudh .  wrote:
>> >>
>> >> Hello Gilles
>> >>
>> >> Thank you very much for your advice. Yes, I copied the templates from
>> the
>> >> master branch to the 1.10.2 release, since the release does not have
>> them.
>> >> And yes, changing the Makefile.am as you suggest did make the autogen
>> error
>> >> go away.
>> >>
>> >> However, in the master branch, the autotools seem to be ignoring the
>> new
>> >> btl directory altogether; i.e. I do not get a Makefile.in from the
>> >> Makefile.am.
>> >>
>> >> In the 1.10.2 release, doing an identical sequence of steps do create a
>> >> Makefile.in from Makefile.am (via autogen) and a Makefile from
>> Makefile.in
>> >> (via configure), but of course, the new BTL does not build because the
>> >> include paths in master and 1.10.2 are different.
>> >>
>> >> My Makefile.am and configure.m4 are as follows. Any thoughts on what it
>> >> would take in the master branch to hook up the new BTL directory?
>> >>
>> >> opal/mca/btl/lf/configure.m4
>> >> # 
>> >> AC_DEFUN([MCA_opal_btl_lf_CONFIG],[
>> >> AC_CONFIG_FILES([opal/mca/btl/lf/Makefile])
>> >> ])dnl
>> >>
>> >> opal/mca/btl/lf/Makefile.am---
>> >> amca_paramdir = $(AMCA_PARAM_SETS_DIR)
>> >> dist_amca_param_DATA = netpipe-btl-lf.txt
>> >>
>> >> sources = \
>> >> btl_lf.c \
>> >> btl_lf.h \
>> >> 

Re: [OMPI devel] [OMPI users] Adding a new BTL

[dpchoudh .]

Hello Gilles

Thank you; the build is successful now.

I do have a generic, unrelated question, though:

I really appreciate how all the principle of object oriented design
principles have been used in OMPI architecture and have been implemented in
a language that is not object oriented. It is a textbook example in
software engineering.

However, I see that functions that are indirectly referenced, via a
structure of function pointers, have been declared 'extern' in header
files. This, to me, looks like against the principle of code design. Making
these 'static' and removing them from the headers does not break the build
of course, and does not even generate warnings. As an example, the
following functions need not be externalized, except, perhaps, for
debugging:

mca_btl_template_module_t mca_btl_template_module = {
.super = {
.btl_component = _btl_template_component.super,
.btl_add_procs = mca_btl_template_add_procs,
.btl_del_procs = mca_btl_template_del_procs,
.btl_register = mca_btl_template_register,
.btl_finalize = mca_btl_template_finalize,
.btl_alloc = mca_btl_template_alloc,
.btl_free = mca_btl_template_free,
.btl_prepare_src = mca_btl_template_prepare_src,
.btl_send = mca_btl_template_send,
.btl_put = mca_btl_template_put,
.btl_get = mca_btl_template_get,
.btl_register_mem = mca_btl_template_register_mem,
.btl_deregister_mem = mca_btl_template_deregister_mem,
.btl_ft_event = mca_btl_template_ft_event
}
};

Is there any reason why it is done this way? If I made them 'static' in my
own BTL code, would I get into trouble down the road?

Thanks
Durga



Life is complex. It has real and imaginary parts.

On Thu, Feb 25, 2016 at 7:02 PM, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:

> on master/v2.x, you also have to
>
> rm -f opal/mca/btl/lf/.opal_ignore
>
> (and this file would have been .ompi_ignore on v1.10)
>
> Cheers,
>
> Gilles
>
> On Fri, Feb 26, 2016 at 7:44 AM, dpchoudh .  wrote:
> > Hello Jeff and other developers:
> >
> > Attached are five files:
> > 1-2: Full output from autogen.pl and configure, captured with: ./
> 2>&1
> > | tee .log
> > 3. Makefile.am of the specific BTL directory
> > 4. configure.m4 of the same directory
> > 5. config.log, as generated internally by autotools
> >
> > Thank you
> > Durga
> >
> >
> > Life is complex. It has real and imaginary parts.
> >
> > On Thu, Feb 25, 2016 at 5:15 PM, Jeff Squyres (jsquyres)
> >  wrote:
> >>
> >> Can you send the full output from autogen and configure?
> >>
> >> Also, this is probably better suited for the Devel list, since we're
> >> talking about OMPI internals.
> >>
> >> Sent from my phone. No type good.
> >>
> >> On Feb 25, 2016, at 2:06 PM, dpchoudh .  wrote:
> >>
> >> Hello Gilles
> >>
> >> Thank you very much for your advice. Yes, I copied the templates from
> the
> >> master branch to the 1.10.2 release, since the release does not have
> them.
> >> And yes, changing the Makefile.am as you suggest did make the autogen
> error
> >> go away.
> >>
> >> However, in the master branch, the autotools seem to be ignoring the new
> >> btl directory altogether; i.e. I do not get a Makefile.in from the
> >> Makefile.am.
> >>
> >> In the 1.10.2 release, doing an identical sequence of steps do create a
> >> Makefile.in from Makefile.am (via autogen) and a Makefile from
> Makefile.in
> >> (via configure), but of course, the new BTL does not build because the
> >> include paths in master and 1.10.2 are different.
> >>
> >> My Makefile.am and configure.m4 are as follows. Any thoughts on what it
> >> would take in the master branch to hook up the new BTL directory?
> >>
> >> opal/mca/btl/lf/configure.m4
> >> # 
> >> AC_DEFUN([MCA_opal_btl_lf_CONFIG],[
> >> AC_CONFIG_FILES([opal/mca/btl/lf/Makefile])
> >> ])dnl
> >>
> >> opal/mca/btl/lf/Makefile.am---
> >> amca_paramdir = $(AMCA_PARAM_SETS_DIR)
> >> dist_amca_param_DATA = netpipe-btl-lf.txt
> >>
> >> sources = \
> >> btl_lf.c \
> >> btl_lf.h \
> >> btl_lf_component.c \
> >> btl_lf_endpoint.c \
> >> btl_lf_endpoint.h \
> >> btl_lf_frag.c \
> >> btl_lf_frag.h \
> >> btl_lf_proc.c \
> >> btl_lf_proc.h
> >>
> >> # Make the output library in this directory, and name it either
> >> # mca__.la (for DSO builds) or libmca__.la
> >> # (for static builds).
> >>
> >> if MCA_BUILD_opal_btl_lf_DSO
> >> lib =
> >> lib_sources =
> >> component = mca_btl_lf.la
> >> component_sources = $(sources)
> >> else
> >> lib = libmca_btl_lf.la
> >> lib_sources = $(sources)
> >> component =
> >> component_sources =
> >> endif
> >>
> >> mcacomponentdir = $(opallibdir)
> >> mcacomponent_LTLIBRARIES = $(component)
> >> mca_btl_lf_la_SOURCES = $(component_sources)
> >> mca_btl_lf_la_LDFLAGS = -module -avoid-version

Re: [OMPI devel] [OMPI users] Adding a new BTL

[Gilles Gouaillardet]

on master/v2.x, you also have to

rm -f opal/mca/btl/lf/.opal_ignore

(and this file would have been .ompi_ignore on v1.10)

Cheers,

Gilles

On Fri, Feb 26, 2016 at 7:44 AM, dpchoudh .  wrote:
> Hello Jeff and other developers:
>
> Attached are five files:
> 1-2: Full output from autogen.pl and configure, captured with: ./ 2>&1
> | tee .log
> 3. Makefile.am of the specific BTL directory
> 4. configure.m4 of the same directory
> 5. config.log, as generated internally by autotools
>
> Thank you
> Durga
>
>
> Life is complex. It has real and imaginary parts.
>
> On Thu, Feb 25, 2016 at 5:15 PM, Jeff Squyres (jsquyres)
>  wrote:
>>
>> Can you send the full output from autogen and configure?
>>
>> Also, this is probably better suited for the Devel list, since we're
>> talking about OMPI internals.
>>
>> Sent from my phone. No type good.
>>
>> On Feb 25, 2016, at 2:06 PM, dpchoudh .  wrote:
>>
>> Hello Gilles
>>
>> Thank you very much for your advice. Yes, I copied the templates from the
>> master branch to the 1.10.2 release, since the release does not have them.
>> And yes, changing the Makefile.am as you suggest did make the autogen error
>> go away.
>>
>> However, in the master branch, the autotools seem to be ignoring the new
>> btl directory altogether; i.e. I do not get a Makefile.in from the
>> Makefile.am.
>>
>> In the 1.10.2 release, doing an identical sequence of steps do create a
>> Makefile.in from Makefile.am (via autogen) and a Makefile from Makefile.in
>> (via configure), but of course, the new BTL does not build because the
>> include paths in master and 1.10.2 are different.
>>
>> My Makefile.am and configure.m4 are as follows. Any thoughts on what it
>> would take in the master branch to hook up the new BTL directory?
>>
>> opal/mca/btl/lf/configure.m4
>> # 
>> AC_DEFUN([MCA_opal_btl_lf_CONFIG],[
>> AC_CONFIG_FILES([opal/mca/btl/lf/Makefile])
>> ])dnl
>>
>> opal/mca/btl/lf/Makefile.am---
>> amca_paramdir = $(AMCA_PARAM_SETS_DIR)
>> dist_amca_param_DATA = netpipe-btl-lf.txt
>>
>> sources = \
>> btl_lf.c \
>> btl_lf.h \
>> btl_lf_component.c \
>> btl_lf_endpoint.c \
>> btl_lf_endpoint.h \
>> btl_lf_frag.c \
>> btl_lf_frag.h \
>> btl_lf_proc.c \
>> btl_lf_proc.h
>>
>> # Make the output library in this directory, and name it either
>> # mca__.la (for DSO builds) or libmca__.la
>> # (for static builds).
>>
>> if MCA_BUILD_opal_btl_lf_DSO
>> lib =
>> lib_sources =
>> component = mca_btl_lf.la
>> component_sources = $(sources)
>> else
>> lib = libmca_btl_lf.la
>> lib_sources = $(sources)
>> component =
>> component_sources =
>> endif
>>
>> mcacomponentdir = $(opallibdir)
>> mcacomponent_LTLIBRARIES = $(component)
>> mca_btl_lf_la_SOURCES = $(component_sources)
>> mca_btl_lf_la_LDFLAGS = -module -avoid-version
>>
>> noinst_LTLIBRARIES = $(lib)
>> libmca_btl_lf_la_SOURCES = $(lib_sources)
>> libmca_btl_lf_la_LDFLAGS = -module -avoid-version
>>
>> -
>>
>> Life is complex. It has real and imaginary parts.
>>
>> On Thu, Feb 25, 2016 at 3:10 AM, Gilles Gouaillardet
>>  wrote:
>>>
>>> Did you copy the template from the master branch into the v1.10 branch ?
>>> if so, you need to replacing MCA_BUILD_opal_btl_lf_DSO with
>>> MCA_BUILD_ompi_btl_lf_DSO will likely solve your issue.
>>> you do need a configure.m4 (otherwise your btl will not be built) but
>>> you do not need AC_MSG_FAILURE
>>>
>>> as far as i am concerned, i would develop in the master branch, and
>>> then back port it into the v1.10 branch when it is ready.
>>>
>>> fwiw, btl used to be in ompi/mca/btl (still the case in v1.10) and
>>> have been moved into opal/mca/btl since v2.x
>>> so it is quite common a bit of porting is required, most of the time,
>>> it consists in replacing OMPI like macros by OPAL like macros
>>>
>>> Cheers,
>>>
>>> Gilles
>>>
>>> On Thu, Feb 25, 2016 at 3:54 PM, dpchoudh .  wrote:
>>> > Hello all
>>> >
>>> > I am not sure if this question belongs in the user list or the
>>> > developer list, but because it is a simpler question I am trying the
>>> > user list first.
>>> >
>>> > I am trying to add a new BTL for a proprietary transport.
>>> >
>>> > As step #0, I copied the BTL template, renamed the 'template' to
>>> > something else, and ran autogen.sh at the top level directory (of
>>> > openMPI 1.10.2). The Makefile.am is identical to what is provided in
>>> > the template except that all the 'template' has been substituted with
>>> > 'lf', the name of the fabric.
>>> >
>>> > With that, I get the following error:
>>> >
>>> > 
>>> >
>>> > autoreconf: running: /usr/bin/autoconf --include=config --force
>>> > --warnings=all,no-obsolete,no-override
>>> > autoreconf: running: /usr/bin/autoheader --include=config --force
>>> > 

Re: [OMPI devel] [OMPI users] Adding a new BTL

[dpchoudh .]

Hello Jeff and other developers:

Attached are five files:
1-2: Full output from autogen.pl and configure, captured with: ./ 2>&1
| tee .log
3. Makefile.am of the specific BTL directory
4. configure.m4 of the same directory
5. config.log, as generated internally by autotools

Thank you
Durga


Life is complex. It has real and imaginary parts.

On Thu, Feb 25, 2016 at 5:15 PM, Jeff Squyres (jsquyres)  wrote:

> Can you send the full output from autogen and configure?
>
> Also, this is probably better suited for the Devel list, since we're
> talking about OMPI internals.
>
> Sent from my phone. No type good.
>
> On Feb 25, 2016, at 2:06 PM, dpchoudh .  wrote:
>
> Hello Gilles
>
> Thank you very much for your advice. Yes, I copied the templates from the
> master branch to the 1.10.2 release, since the release does not have them.
> And yes, changing the Makefile.am as you suggest did make the autogen error
> go away.
>
> However, in the master branch, the autotools seem to be ignoring the new
> btl directory altogether; i.e. I do not get a Makefile.in from the
> Makefile.am.
>
> In the 1.10.2 release, doing an identical sequence of steps do create a
> Makefile.in from Makefile.am (via autogen) and a Makefile from Makefile.in
> (via configure), but of course, the new BTL does not build because the
> include paths in master and 1.10.2 are different.
>
> My Makefile.am and configure.m4 are as follows. Any thoughts on what it
> would take in the master branch to hook up the new BTL directory?
>
> opal/mca/btl/lf/configure.m4
> # 
> AC_DEFUN([MCA_opal_btl_lf_CONFIG],[
> AC_CONFIG_FILES([opal/mca/btl/lf/Makefile])
> ])dnl
>
> opal/mca/btl/lf/Makefile.am---
> amca_paramdir = $(AMCA_PARAM_SETS_DIR)
> dist_amca_param_DATA = netpipe-btl-lf.txt
>
> sources = \
> btl_lf.c \
> btl_lf.h \
> btl_lf_component.c \
> btl_lf_endpoint.c \
> btl_lf_endpoint.h \
> btl_lf_frag.c \
> btl_lf_frag.h \
> btl_lf_proc.c \
> btl_lf_proc.h
>
> # Make the output library in this directory, and name it either
> # mca__.la (for DSO builds) or libmca__.la
> # (for static builds).
>
> if MCA_BUILD_opal_btl_lf_DSO
> lib =
> lib_sources =
> component = mca_btl_lf.la
> component_sources = $(sources)
> else
> lib = libmca_btl_lf.la
> lib_sources = $(sources)
> component =
> component_sources =
> endif
>
> mcacomponentdir = $(opallibdir)
> mcacomponent_LTLIBRARIES = $(component)
> mca_btl_lf_la_SOURCES = $(component_sources)
> mca_btl_lf_la_LDFLAGS = -module -avoid-version
>
> noinst_LTLIBRARIES = $(lib)
> libmca_btl_lf_la_SOURCES = $(lib_sources)
> libmca_btl_lf_la_LDFLAGS = -module -avoid-version
>
> -
>
> Life is complex. It has real and imaginary parts.
>
> On Thu, Feb 25, 2016 at 3:10 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
>
>> Did you copy the template from the master branch into the v1.10 branch ?
>> if so, you need to replacing MCA_BUILD_opal_btl_lf_DSO with
>> MCA_BUILD_ompi_btl_lf_DSO will likely solve your issue.
>> you do need a configure.m4 (otherwise your btl will not be built) but
>> you do not need AC_MSG_FAILURE
>>
>> as far as i am concerned, i would develop in the master branch, and
>> then back port it into the v1.10 branch when it is ready.
>>
>> fwiw, btl used to be in ompi/mca/btl (still the case in v1.10) and
>> have been moved into opal/mca/btl since v2.x
>> so it is quite common a bit of porting is required, most of the time,
>> it consists in replacing OMPI like macros by OPAL like macros
>>
>> Cheers,
>>
>> Gilles
>>
>> On Thu, Feb 25, 2016 at 3:54 PM, dpchoudh .  wrote:
>> > Hello all
>> >
>> > I am not sure if this question belongs in the user list or the
>> > developer list, but because it is a simpler question I am trying the
>> > user list first.
>> >
>> > I am trying to add a new BTL for a proprietary transport.
>> >
>> > As step #0, I copied the BTL template, renamed the 'template' to
>> > something else, and ran autogen.sh at the top level directory (of
>> > openMPI 1.10.2). The Makefile.am is identical to what is provided in
>> > the template except that all the 'template' has been substituted with
>> > 'lf', the name of the fabric.
>> >
>> > With that, I get the following error:
>> >
>> > 
>> >
>> > autoreconf: running: /usr/bin/autoconf --include=config --force
>> > --warnings=all,no-obsolete,no-override
>> > autoreconf: running: /usr/bin/autoheader --include=config --force
>> > --warnings=all,no-obsolete,no-override
>> > autoreconf: running: automake --add-missing --copy --force-missing
>> > --warnings=all,no-obsolete,no-override
>> > configure.ac:320: installing 'config/compile'
>> > configure.ac:73: installing 'config/config.guess'
>> > configure.ac:73: installing 'config/config.sub'
>> > configure.ac:93: installing 'config/install-sh'
>> > configure.ac:93: 

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Jeff Squyres (jsquyres)]

> On Feb 25, 2016, at 3:39 PM, Paul Hargrove  wrote:
> 
> A "bare" function name (without parens) is the address of the function, which 
> can be converted to an int, long, etc.
> So the "rank" identifier can validly refer to the function in this context.

I understand that there's logic behind this.  But it's still crazy to me that:

-
int foo(void) {
  int rank;
  printf("Value: %d", rank);
}
-

is ambiguous.

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

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Paul Hargrove]

On Thu, Feb 25, 2016 at 1:27 PM, Jeff Squyres (jsquyres)  wrote:

> I still find it fairly astounding that the naked word "rank" (vs "rank()")
> is ambiguous with a variable and a function call.  I wouldn't be surprised
> by this in a scripting language; if this really is true in C++, that's
> quite surprising to me.


A "bare" function name (without parens) is the address of the function,
which can be converted to an int, long, etc.
So the "rank" identifier can validly refer to the function in this context.

This is no different than C with respect to typing rules:

$ cat foo.c
#include 
int main(void) { printf("%ld\n", main); }
$ gcc -o foo foo.c
$ ./foo
134513448


-Paul

-- 
Paul H. Hargrove  phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Jeff Squyres (jsquyres)]

On Feb 25, 2016, at 3:14 PM, Dave Goodell (dgoodell)  wrote:
> 
>> So you can't have a local variable named "rank" any more?  That's... 
>> terrible!
> 
> Or you could avoid "using namespace std".  Or qualify it using "::rank" (I 
> think, my C++ is rusty).

Yeah, fair enough.  But I don't think we can guarantee that the user won't 
"using namespace std", so prefixing with :: is probably the right thing to do.

I still find it fairly astounding that the naked word "rank" (vs "rank()") is 
ambiguous with a variable and a function call.  I wouldn't be surprised by this 
in a scripting language; if this really is true in C++, that's quite surprising 
to me.

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

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Paul Hargrove]

On Thu, Feb 25, 2016 at 1:05 PM, Jeff Squyres (jsquyres)  wrote:

> On Feb 25, 2016, at 2:59 PM, Paul Hargrove  wrote:
> >
> > Not an error - a new API in C++11 to get number of dimensions in a
> multi-dimensional array.
> > http://en.cppreference.com/w/cpp/types/rank
>
> So you can't have a local variable named "rank" any more?  That's...
> terrible!


If (and only if) one is "using namespace std;" you can no longer use "rank".
You already can't use "string" or "list" (among others) as identifiers
under the same conditions.

So, removing "using namespace std;" from the C++ code (and adding std:: as
necessary) should fix the problem.
If it does not, *then* I'd say there is a bug somewhere.

-Paul

-- 
Paul H. Hargrove  phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Dave Goodell (dgoodell)]

On Feb 25, 2016, at 4:05 PM, Jeff Squyres (jsquyres)  wrote:
> 
> On Feb 25, 2016, at 2:59 PM, Paul Hargrove  wrote:
>> 
>> Not an error - a new API in C++11 to get number of dimensions in a 
>> multi-dimensional array.
>> http://en.cppreference.com/w/cpp/types/rank
> 
> So you can't have a local variable named "rank" any more?  That's... terrible!

Or you could avoid "using namespace std".  Or qualify it using "::rank" (I 
think, my C++ is rusty).

-Dave

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Jeff Squyres (jsquyres)]

On Feb 25, 2016, at 2:59 PM, Paul Hargrove  wrote:
> 
> Not an error - a new API in C++11 to get number of dimensions in a 
> multi-dimensional array.
> http://en.cppreference.com/w/cpp/types/rank

So you can't have a local variable named "rank" any more?  That's... terrible!

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

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Paul Hargrove]

Jeff,

Not an error - a new API in C++11 to get number of dimensions in a
multi-dimensional array.
http://en.cppreference.com/w/cpp/types/rank

-Paul

On Thu, Feb 25, 2016 at 12:06 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:

> That looks like the c++ headers in gcc 6.0 beta are busted - it looks like
> there's a "rank" variable in the local scope from the STL headers
> somehow...?
>
> Sent from my phone. No type good.
>
> > On Feb 25, 2016, at 10:52 AM, Adrian Reber  wrote:
> >
> > I installed a pre-release gcc 6.0
> >
> > gcc version 6.0.0 20160221 (experimental) (GCC)
> >
> > on my MTT systems (ppc64 and x86_64) and I now get a
> > test build failure:
> >
> > https://mtt.open-mpi.org/index.php?do_redir=2269
> >
> > Just as a FYI.
> >
> >Adrian
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2016/02/18616.php
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2016/02/18617.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Jeff Squyres (jsquyres)]

That looks like the c++ headers in gcc 6.0 beta are busted - it looks like 
there's a "rank" variable in the local scope from the STL headers somehow...?

Sent from my phone. No type good. 

> On Feb 25, 2016, at 10:52 AM, Adrian Reber  wrote:
> 
> I installed a pre-release gcc 6.0
> 
> gcc version 6.0.0 20160221 (experimental) (GCC)
> 
> on my MTT systems (ppc64 and x86_64) and I now get a
> test build failure:
> 
> https://mtt.open-mpi.org/index.php?do_redir=2269
> 
> Just as a FYI.
> 
>Adrian
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2016/02/18616.php

[OMPI devel] MTT setup updated to gcc-6.0 (pre)

[Adrian Reber]

I installed a pre-release gcc 6.0

 gcc version 6.0.0 20160221 (experimental) (GCC)

on my MTT systems (ppc64 and x86_64) and I now get a
test build failure:

https://mtt.open-mpi.org/index.php?do_redir=2269

Just as a FYI.

Adrian