octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #63210] Lots of warnings in compilation


From: Rik
Subject: [Octave-bug-tracker] [bug #63210] Lots of warnings in compilation
Date: Sun, 30 Oct 2022 11:39:45 -0400 (EDT)

Follow-up Comment #9, bug #63210 (project octave):

For the remaining warnings I don't see particularly easy fixes.

1) Error in oct-tex-parser.cc
This is a generated file by the Lex/Yacc chain and unless there is an option
to disable generation of this error feature then we are stuck with the
warning

2) Error in oct-rl-edit.c.
This seems to be related to which version of GNU readline is being used.  If
the system has older versions of readline installed then the function
rl_completer_word_break_characters has a return value of pointer to char. 
Newer versions of readline have a return value of const pointer to char.  We
could, maybe, cast away the const attribute always.  Or we could have #ifdef
code to have two different prototypes for this function based on the signature
of the function in the readline library.  All of this sounds like a lot of
work for minimal gain

3) Errors in GraphicsMagick STL.h

I see tons of warnings like the one below:


/usr/include/GraphicsMagick/Magick++/STL.h:65:46: warning:
'unary_function<Magick::Image &, void>' is deprecated
[-Wdeprecated-declarations]


This isn't, as far as I know, an Octave problem.  But maybe we should report
it to the GraphicsMagick team.

4) Warnings about unnecessary use of '-pthread'

I see lots of warnings like 


clang-15: warning: argument unused during compilation: '-pthread'
[-Wunused-command-line-argument]


This is pretty minor since it is just saying the argument was unused/ignored
during compilation.  But if it were simple to suppress I think that would be a
good idea because warnings make people think there is something wrong.

5) Texinfo errors

I am seeing errors like


Chapter 3 [40] [41] [42] [43] [44] Warning: unbalanced parentheses in @def...


during the generation of the documentation.  I should be able to fix these,
although finding them can sometimes be hard because it can be a subtle
difference if someone has accidentally closed a macro with a '}' versus a ')'.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63210>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]