+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 <bosi...@icl.utk.edu> 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 . <dpcho...@gmail.com> 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 = &mca_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 . <dpcho...@gmail.com> wrote:
> > Hello Jeff and other developers:
> >
> > Attached are five files:
> > 1-2: Full output from autogen.pl and configure, captured with: ./<cmd> 2>&1
> > | tee <cmd>.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)
> > <jsquy...@cisco.com> 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 . <dpcho...@gmail.com> 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_<type>_<name>.la (for DSO builds) or libmca_<type>_<name>.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 . <dpcho...@gmail.com> 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:
> >>> >
> >>> > <snip>
> >>> >
> >>> > 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: installing 'config/missing'
> >>> > ompi/Makefile.am: installing 'config/depcomp'
> >>> > ompi/mca/btl/lf/Makefile.am:33: error: MCA_BUILD_opal_btl_lf_DSO does
> >>> > not appear in AM_CONDITIONAL
> >>> >
> >>> >
> >>> > I tried adding a configure.m4 file to the btl directory with the
> >>> > following content:
> >>> >
> >>> > # MCA_btl_lf_CONFIG([action-if-can-compile],
> >>> > # [action-if-cant-compile])
> >>> > # ------------------------------------------------
> >>> > AC_DEFUN([MCA_ompi_btl_lf_CONFIG],[
> >>> > AC_CONFIG_FILES([ompi/mca/btl/lf/Makefile])
> >>> > AC_MSG_FAILURE
> >>> > ])dnl
> >>> >
> >>> >
> >>> > but the error remains.
> >>> >
> >>> > I am sure I am missing at least one step, but am lost in the huge
> >>> > codebase. Please help.
> >>> >
> >>> > Thank you
> >>> > Durga
> >>> >
> >>> > Life is complex. It has real and imaginary parts.
> >>> > _______________________________________________
> >>> > users mailing list
> >>> > us...@open-mpi.org
> >>> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>> > Link to this post:
> >>> > http://www.open-mpi.org/community/lists/users/2016/02/28575.php
> >>> _______________________________________________
> >>> users mailing list
> >>> us...@open-mpi.org
> >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> >>> Link to this post:
> >>> http://www.open-mpi.org/community/lists/users/2016/02/28576.php
> >>
> >>
> >> _______________________________________________
> >> users mailing list
> >> us...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> >> Link to this post:
> >> http://www.open-mpi.org/community/lists/users/2016/02/28577.php
> >>
> >>
> >> _______________________________________________
> >> users mailing list
> >> us...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> >> Link to this post:
> >> http://www.open-mpi.org/community/lists/users/2016/02/28578.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/18625.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/18626.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/18627.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/18628.php
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
