On Sep 30, 2009, at 7:46 PM, George Bosilca wrote:
In other words, we can safely remove the _DECLSPEC for all debugging
symbols and today this will work. However, if we want to avoid having
issues with them in the future (when the compiler and linked will be
much much much more smarter) I think
After spending few hours reading through some pretty good papers about
shared libraries, I came to the conclusion that somehow this whole
stuff is even more obfuscated that one might think. If I understand
correctly, there is no need for all local symbols to be visible at
all. The linker
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
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
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 make
sure it is externally visible, i.e. flagged with OMPI_DECLSPEC (for
the one in
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
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.
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
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 why it's not
static so that we don't repeat this conversation again next year. ;-)
I think not
On Mon, Sep/28/2009 03:11:46PM, Ethan Mallove wrote:
> On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> > Try a newer compiler than gcc 3.4 -- it's pretty ancient.
>
> I don't get the warning with 4.1.2 either.
To get the warning I needed to enable some developer configure options (e.g.,
On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> Try a newer compiler than gcc 3.4 -- it's pretty ancient.
I don't get the warning with 4.1.2 either.
-Ethan
>
>
> On Sep 28, 2009, at 2:03 PM, Ethan Mallove wrote:
>
>> On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
>> > I think there
Try a newer compiler than gcc 3.4 -- it's pretty ancient.
On Sep 28, 2009, at 2:03 PM, Ethan Mallove wrote:
On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
> I think there is a problem with this change - here is a warning I
get when
> compiling on Mac and Linux:
>
>
On Fri, Sep/25/2009 09:31:51PM, Ralph Castain wrote:
> I think there is a problem with this change - here is a warning I get when
> compiling on Mac and Linux:
>
> ompi_debuggers.c:265: warning: no previous prototype for ?MPIR_Breakpoint?
>
> Can you please take a look?
Can you send me your
I think there is a problem with this change - here is a warning I get
when compiling on Mac and Linux:
ompi_debuggers.c:265: warning: no previous prototype for
‘MPIR_Breakpoint’
Can you please take a look?
Thanks
Ralph
On Sep 25, 2009, at 1:14 PM, emall...@osl.iu.edu wrote:
Author:
13 matches
Mail list logo
