GCC warns me also about "format not a string literal and no format
arguments". I remember this was once discussed on the ML but I'm not
sure what the result was: the call is correct but the G_warning
function needs some GCC attributes to specify what it is?
Glynn:
G_warning() already has a "format" attribute, which is why gcc
complains about the format string not being a string literal.
However, G_gettext() needs a "format_arg" attribute to to tell gcc
that one of arguments may be a format string, so that it stillcan
perform argument checking (and not generate "not a string literal"
warnings) when a format string is passed through that function (the
_(...) macro expands to a G_gettext() call when --with-nls is used).
Done in r57238.
With that change there are still 208 such warnings, but most of them
appear to indicate genuine bugs, i.e. passing arbitrary strings as
format strings, which will fail (e.g. crash) if the string contains
any % characters.
I'm seeing this pop up in Debian/unstable, where -Werror=format-security
is now encouraged to be the default.
there are also quite a few like "G_fatal_error(buff);", can anything
be done in the lib fn for them or do they all have to be changed to
"G_fatal_error("%s", buff);" ? [* many of those are hold-overs from pre-
GRASS 5 and a sprintf(buff,..) in the lines above can be moved into the
G_fatal_error()]
Lots of "G_warning(msg);" and "G_debug(3, db_get_string(&sql));" to
consider too.
Yes for 6.5, probably not for 6.4 as it isn't urgent; the change only
suppresses warnings about "potential" issues, it doesn't fix actual
bugs.
there are also quite a few like "G_fatal_error(buff);", can anything
be done in the lib fn for them or do they all have to be changed to
"G_fatal_error("%s", buff);" ?
They need to be changed. But not necessarily like that. First, ask why
the error message is a variable rather than a string literal.
If it's because error handling has been "wrapped", then unwrap it.
E.g. we might decide to add an option to replace G_fatal_error (and
similar) with a macro which (optionally) adds __FILE__ and __LINE__,
but that's useless if the calls have been wrapped.
[* many of those are hold-overs from pre- GRASS 5 and a
sprintf(buff,..) in the lines above can be moved into the
G_fatal_error()]
In such cases, the sprintf() should be eliminated.
Lots of "G_warning(msg);"
Again: ask "why isn't 'msg' a string literal" first.
and "G_debug(3, db_get_string(&sql));" to consider too.
For most of these, inserting the "%s" is probably the right solution,
although including a word or two of descriptive text might make the
debug information more useful (e.g. providing something to grep for).
I am now trying to run GRASS 7 with IBM's LoadLeveler. While I got the
job definition done, I struggle with a single library which isn't
found.
I tried both with GRASS compiled with shared libraries and as static
binaries (see below):
-bash-3.2$ llsubmit launch_IBM_LL_grassjob_rsun.sh
llsubmit: The job "f01c12p01-hf0.vs.savba.sk.9714" has been submitted.
-bash-3.2$ tail grassgis7_job.err
Could not load module libstdc++.a(libstdc++.so.6).
System error: No such file or directory
Could not load program g.version:
Dependent module libstdc++.a(libstdc++.so.6) could not be loaded.
Could not load module libstdc++.a(libstdc++.so.6).
System error: No such file or directory
Could not load program g.mlist:
Dependent module libstdc++.a(libstdc++.so.6) could not be loaded.
Could not load module libstdc++.a(libstdc++.so.6).
System error: No such file or directory
Here some debug output:
-bash-3.2$ cat grassgis7_job.out
************ Starting job at Fri Aug 23 00:24:47 CEST 2013 on node
f01c03p01-hf0 *************
Processing elevation (target mapset: solar) ...
-------------
PATH:
/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java5/jre/bin:/usr/java5/bin:/gpfs/home/neteler/bin/bin:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/scripts
-------------
LIBS in LD_LIBRARY_PATH:
/opt/freeware/lib:/gpfs/home/neteler/bin/lib/:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib
-------------
-bash-3.2$ ls -la /opt/freeware/lib/libstdc++.a
lrwxrwxrwx 1 root system 44 Jun 10 11:48
/opt/freeware/lib/libstdc++.a ->
gcc/powerpc-ibm-aix7.1.0.0/4.6.1/libstdc++.a
-bash-3.2$ ls -la /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.6.1/libstdc++.a
-rwxr-xr-x 1 root system 11163967 Jul 21 2011
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.6.1/libstdc++.a
I don't understand how to convince the system in LoadLeveler mode that
libstdc++.a is available.
(the binaries run fine from interactive command line).
On Fri, Aug 23, 2013 at 12:32 AM, Markus Neteler <neteler@osgeo.org> wrote:
...
-bash-3.2$ ls -la /opt/freeware/lib/libstdc++.a
lrwxrwxrwx 1 root system 44 Jun 10 11:48
/opt/freeware/lib/libstdc++.a ->
gcc/powerpc-ibm-aix7.1.0.0/4.6.1/libstdc++.a
I guess that the problem is here the relative and not absolute path.
...
I don't understand how to convince the system in LoadLeveler mode that
libstdc++.a is available.
(the binaries run fine from interactive command line).
Most of the code compiles but the HTML page generation fails for
modules which use $(GPROJLIB):
Example:
gmake[3]: Entering directory
`/gpfs/home/neteler/software/grass-7.0.svn/display/d.grid'
: && gcc -L/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib
-L/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib
-maix64 -Wl,-bbigtoc -lm -lstdc++ -lmass -lsqlite3 -lpthread
/opt/freeware/lib/libiconv.a
-Wl,-bsvr4,-R,/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib
-o /gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin/d.grid
OBJ.powerpc-ibm-aix7.1.0.0/plotborder.o
OBJ.powerpc-ibm-aix7.1.0.0/main.o OBJ.powerpc-ibm-aix7.1.0.0/plot.o
OBJ.powerpc-ibm-aix7.1.0.0/fiducial.o -lgrass_display.7.0.svn
-lgrass_gproj.7.0.svn -lgrass_symb.7.0.svn -lgrass_gis.7.0.svn
ld: 0711-224 WARNING: Duplicate symbol: __fe_def_env
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
if [ "/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin/d.grid"
!= "" ] ; then GISRC=/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/demolocation/.grassrc70
GISBASE=/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0
PATH="/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/scripts:$PATH"
PYTHONPATH="/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/etc/python:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/etc/python:$PYTHONPATH"
LIBPATH="/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib:/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib:-L/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib
-L/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib"
LC_ALL=C /gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin/d.grid
--html-description < /dev/null | grep -v '</body>\|</html>' >
d.grid.tmp.html ; fi
Could not load program
/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/bin/d.grid:
Could not load module
/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib/libgrass_gproj.7.0.svn.so.
Dependent module libstdc++.a(libstdc++.so.6) could not be loaded.
Could not load module libstdc++.a(libstdc++.so.6).
System error: No such file or directory
Could not load module d.grid.
Dependent module
/gpfs/home/neteler/software/grass-7.0.svn/dist.powerpc-ibm-aix7.1.0.0/lib/libgrass_gproj.7.0.svn.so
could not be loaded.
Could not load module .
gmake[3]: *** [d.grid.tmp.html] Error 1