On Mon, Apr 30, 2012 at 10:00 AM, Jordi Gutiérrez Hermoso
<jord...@octave.org> wrote:
> On 29 April 2012 19:42, Claudio Freire <klaussfre...@gmail.com> wrote:
>> Here[0] is a patch that makes octave-forge build under gcc 4.7 and
>> another[1] for openmpi 1.5.
>
> Thanks. I looked at your modifications, and they mostly seem safe for
> earlier versions of gcc. Did 4.7 now decide that no return in non-void
> functions is now an error, not just a warning? Is this standard
> behaviour? I'm just curious.
Actually, I think it was 4.6 the one that became pedantic about that.
The patch contains a few fixes for 4.6, rather than 4.7. I just didn't
want to go into that much detail in the initial post ;)
But yes, it changed from a warning to an error at some point. It was
always an error when there was no return whatsoever, but just a
warning when a possible execution path had no return but others did.
They changed that into an error in 4.6 I believe.
>
> Can you please comment on the following modifications?
>
> --- octave-forge.orig/miscellaneous-1.0.11/src/xmltree_read.c
> +++ octave-forge/miscellaneous-1.0.11/src/xmltree_read.c
> @@ -2258,7 +2258,7 @@ case 49:
> XML__RULE_SETUP
> #line 406 "xmltree_read.l"
> {
> - LEAVE; STag_scalar(); pcdata = BUFFERSET(pcdata); ENTER(IN_scalar);
> + LEAVE; STag_scalar(); BUFFERSET(pcdata); ENTER(IN_scalar);
> }
> XML__BREAK
> case 50:
Sorry, that one isn't mine, that's the package's previous mantainer.
Let me revert it and see what happens.
> --- octave-forge.orig/control-2.2.5/src/AB13BD.f 2009-12-04
> 01:46:15.000000000 -0300
> +++ octave-forge/control-2.2.5/src/AB13BD.f 2012-02-02
> 13:02:17.678456705 -0300
> @@ -292,6 +292,7 @@
> C
> C Error return.
> C
> + AB13BD = ZERO
> CALL XERBLA( 'AB13BD', -INFO )
> RETURN
> END IF
>
> I'm just curious how you found these and why do they need to be
> changed.
There, without it, it complains about uninitialized access to AB13BD.
It's quite probably a compiler shortcoming combined with stricter
checks.
> I'm not sure about these sort of changes:
>
> --- octave-forge.orig/parallel-2.0.5/src/send.cc 2012-04-29
> 16:25:21.907000132 -0300
> +++ octave-forge/parallel-2.0.5/src/send.cc 2012-04-29
> 16:25:33.409000132 -0300
> @@ -25,6 +25,7 @@
> #include <sys/poll.h>
> #include <netinet/in.h>
> #include <netdb.h>
> +#include <unistd.h>
>
> Octave-Forge isn't only compiled for Unix-like systems, so this
> #include will break compilation on Windows. We probably need an
> autoconf macro to check for unistd.h. Can you write one?
In that case, you could probably wrap it in:
#if (!defined(__WIN32__) && !defined(__CYGWIN__))
#include <unistd.h>
#endif
>> The openmpi patch shows undue reliance on internal openmpi state,
>> something which is the cause of trouble. I don't know enough of that
>> functionality to find a better fix, so I'll leave it up to you guys
>> ;-)
>
> I'm not sure about this patch. Checking for version numbers is Evil™,
> because if a future version disables what you were checking for, then
> your check is worthless. You should instead check for functionality,
> not for version numbers. It would be better to write some autoconf
> macro that toggles HAVE_STAT_UCOUNT or whatever. Can you also write
> one?
Thing is, the field _count is clearly marked as internal in openmpi.
It's simply an error to use it no matter how. It should be replaced by
an API call, but I honestly don't know that much about openmpi.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
