On the positive side: it did solve the compiler warning issue.
Not saying I disagree with these points.
On Sep 30, 2009, at 4:01 AM, Jeff Squyres wrote:
> I still don't think these need to be DECLSPEC. Debuggers can find
> local symbols (including static symbols). Sun was having a problem
> with the Intel compilers because the function was being inlined --
> and therefore the symbol didn't exist at all.
> Removing the "static" was a simple optimization to force the intel
> compiler to *not* inline the function. That's all.
> We should *not* be exposing the MPIR_Breakpoint function to user
> applications who -lmpi. That is what putting DECLSPEC there will do.
> I believe that the DECLSPEC should be removed.
> On Sep 30, 2009, at 12:08 AM, George Bosilca wrote:
>> Ethan is right. The MPIR_Breakpoint function will be queried by your
>> preferred parallel debugger, in order to set a breakpoint. Therefore,
>> to allow the debuggers to be able to find the function we have to
>> sure it is externally visible, i.e. flagged with OMPI_DECLSPEC (for
>> the one in libmpi) and with ORTE_DECLSPEC for the one in libopen-rte.
>> And yes, we really need the *_DECLSPEC to make it visible, extern is
>> not enough.
>> Moreover, looking in the ompi/debugger/debugger.h file I realized
>> the two functions declared inside are flagged OMPI_DECLSPEC when they
>> should not have been, as these two functions are not called from
>> outside the libmpi.
>> Please try r22032.
>> On Sep 29, 2009, at 17:55 , Jeff Squyres wrote:
>> > On Sep 29, 2009, at 5:30 PM, Ralph Castain wrote:
>> >> The issue isn't why or why not static, Jeff - the issue is that we
>> >> get
>> >> a compiler warning whenever we do a developer build.
>> > Right. The initial issue was the static-ness, though -- Ethan
>> > removed the static because some compilers were effectively inlining
>> > the function (and therefore removing the symbol from the library,
>> > making the parallel debugger attach stuff not work) presumably
>> > because a) the function was static, b) the function was short with
>> > no side effects, and c) the function was only called once within
>> > that .c file.
>> > Removing the "static" from the function prototype violated those
>> > assumptions so that it could no longer be inlined (And therefore
>> > symbol definitely appears in the library). But then we ran across
>> > the "must be prototyped" warning.
>> > That's where all this came from. :-)
>> > So -- I still don't think we need to DECLSPEC the prototype. :-)
>> >> On Sep 29, 2009, at 2:32 PM, Jeff Squyres wrote:
>> >> > I don't think we need to DECLSPEC it, do we? We don't need (or
>> >> > want) this symbol to be visible at the link level when user apps
>> >> > link against libmpi. You might want to put in a comment about
>> >> > it's not static so that we don't repeat this conversation again
>> >> next
>> >> > year. ;-)
>> >> >
>> >> > I think not having it DECLSPEC'ed should still work for the
>> >> debugger
>> >> > (since it worked before when it was static), but if you could
>> >> > it to be sure, that would be great...
>> > --
>> > Jeff Squyres
>> > jsquyres_at_[hidden]
>> > _______________________________________________
>> > devel mailing list
>> > devel_at_[hidden]
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> devel mailing list
> Jeff Squyres
> devel mailing list