[GRASS-dev] r54684 - db_sqltype_name(): report variable-width string instead of fixed-width n-character string
Hi Martin, what is the reason for r54684? It breaks a core functionality, i.e. the output of vector_columns in lib/python/scripts/vector.py has now changed and various scripts rely on that output. I have reverted r54684 in 55475. The commit comment does not make sense to me because db_sqltype_name() has never returned the width or precision. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Quiet module output
Hi, thank you for the hint with GRASS_VERBOSE... GRASS_VERBOSE [all modules] toggles verbosity level 0 - only errors and warnings are printed 1 - progress messages are printed (percent complete) 2 - all module messages are printed 3 - additional verbose messages are printed This variable is automatically created by g.parser so that the --verbose or --quiet flags will be inherited by dependent modules as the script runs. What is still unclear to me: Setting the --quiet flag in a script using g.parser (what I am doing) automatically sets the GRASS_VERBOSE variable to 1? I'd like to get all grass_fatal(_()) error messages of my own script but no progress message for all dependent modules in the script (GRASS_VERBOSE=0). So how can I set the GRASS_VERBOSE to 0 for a script so it is inherited to all underlying modules, as it seems there is no g.parser flag provided for 0? Therefore, is e.g. g.gisenv set=GRASS_VERBOSE=0 before running the script or including that line within the script the way to go? /johannes On Wed, Mar 20, 2013 at 10:01 PM, Nikos Alexandris n...@nikosalexandris.net wrote: On Wednesday 20 of March 2013 15:00:23 Johannes Radinger wrote: Hi, I just wanted to ask how the quiet-flag is defined. I mean, what will be still reported to the screen (console)? How is it with self-written e.g. add-ons in python. If quiet is set are all grass output messages automatically suppressed? What about the status report of counting percentages (0%...100%) in general? If I remember correctly they are not suppressed in r.cost. That is slightly annoying when running such modules in loops and the screen gets completely covered with 100%s... Johannes, you do know the related environment variables GRASS_MESSAGE_FORMAT GRASS_VERBOSE right? Check http://grass.osgeo.org/grass64/manuals/variables.html. Especially for the VERBOSE one, the manual states: This variable is automatically created by g.parser so that the --verbose or --quiet flags will be inherited by dependent modules as the script runs. Best, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] osgeo4w-wingrass 7 broken
Hi, 2013/3/20 Helmut Kudrnovsky hel...@web.de: it seems osgeo4w-wingrass 7 broken is broken: grass70-dev-7.0.svn-r55463-527.tar.bz2 = ~18 MB earlier versions grass70-dev-7.0.svn-r55431-526.tar.bz2 = ~25 MB right, something is broken in OSGeo4W framework. Will check it. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] osgeo4w-wingrass 7 broken
013/3/21 Martin Landa landa.mar...@gmail.com: it seems osgeo4w-wingrass 7 broken is broken: grass70-dev-7.0.svn-r55463-527.tar.bz2 = ~18 MB earlier versions grass70-dev-7.0.svn-r55431-526.tar.bz2 = ~25 MB right, something is broken in OSGeo4W framework. Will check it. Martin missing checking whether to use regex... yes checking for location of regex includes... checking for regex.h... no configure: error: *** Unable to locate regex includes. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1757: LD_SEARCH_FLAGS incorrect for NetBSD
#1757: LD_SEARCH_FLAGS incorrect for NetBSD
-+--
Reporter: brook| Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: |Platform: Other Unix
Cpu: Unspecified |
-+--
Comment(by mmetz):
Replying to [comment:2 glynn]:
7.0 doesn't support any BSD systems yet. New platforms need to be added
by people who actually have access to (and preferably knowledge of) the
platform in question.
7.0 supports now FreeBSD.
However, I do not get 7.0 compiled on NetBSD 6.0.1, the error is
{{{
ld: unrecognized option '-Wl,-rpath,/home/metz/src/grass-7.0.svn/dist.i386
-unknown-netbsdelf6.0.1/lib'
}}}
ld is GNU ld (NetBSD Binutils nb1) 2.21.1
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1757#comment:3
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Quiet module output
On 21/03/13 11:18, Johannes Radinger wrote: Hi, thank you for the hint with GRASS_VERBOSE... GRASS_VERBOSE [all modules] toggles verbosity level 0 - only errors and warnings are printed 1 - progress messages are printed (percent complete) 2 - all module messages are printed 3 - additional verbose messages are printed This variable is automatically created by g.parser so that the --verbose or --quiet flags will be inherited by dependent modules as the script runs. What is still unclear to me: Setting the --quiet flag in a script using g.parser (what I am doing) automatically sets the GRASS_VERBOSE variable to 1? --quiet should set it to 0 (actually to MINLEVEL, but that is defined as 0 in lib/gis/verbose.c). I can confirm that: r.stats elevation -c gives me the percent complete info. r.stats elevation -c --quiet doesn't. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Programming manual updated
Another update of Vector library page. List of functions was moved to a separate page and sectioning was changed. I would like to group existing subsections of that page more but I don't know the library enough to do this grouping. Vaclav http://grass.osgeo.org/programming7/vectorlib.html http://grass.osgeo.org/programming7/vlibLists.html (I suppose this link) PS: MarkusN, please, generate the manual. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxGUI spin control for floating point ???
What is the reason to have a spin control for floating point values? Could the spin control at least not use the number but the significant digits (same like printing with %g) for spinning? E.g. for 0.0001 I see 0.000 which is wrong. IMHO the spin control should be reverted to text input. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI spin control for floating point ???
Hi, 2013/3/21 Markus Metz markus.metz.gisw...@gmail.com: What is the reason to have a spin control for floating point values? Could the spin control at least not use the number but the significant digits (same like printing with %g) for spinning? E.g. for 0.0001 I see 0.000 which is wrong. IMHO the spin control should be reverted to text input. sometimes float spin controls are useful sometimes not. Useful eg. `d.vect size`, but not for the case you mentioned. Probably we could stay with floating spin control (some improvements required) rather than plain text input. No strong opinion here. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Programming manual updated
On Thu, Mar 21, 2013 at 12:12 PM, Vaclav Petras wenzesl...@gmail.com wrote: ... http://grass.osgeo.org/programming7/vectorlib.html http://grass.osgeo.org/programming7/vlibLists.html (I suppose this link) PS: MarkusN, please, generate the manual. Done so! Nice work. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Quiet module output
I agree, --quiet set GRASS_VERBOSE to 0. But this is not always inherited. Eg. in one of my python scripts I use the GRASS-Numpy interface (http://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Interfacing_with_NumPy) My script is very similar to the example in the wiki, where I use .read() to get GRASS maps into numpy and .write() to get numpy arrays to GRASS. And here the .write() uses actually r.bin.in to write the file back into grass. For this process the progress message (...100%) is shown still although the flag quiet is set for the entire script. Looking at the debugging output when running the script I see that 1) the .read() uses r.out.bin --q but the .write() uses r.in.bin --v. So is that setting respectively the definition of .write() with the verbose-flag interfering? Anybody an idea how to fix that, so that the GRASS_VERBOSE variable is also inherited to .write() commands in a python.script? /johannes On Thu, Mar 21, 2013 at 11:49 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/03/13 11:18, Johannes Radinger wrote: Hi, thank you for the hint with GRASS_VERBOSE... GRASS_VERBOSE [all modules] toggles verbosity level 0 - only errors and warnings are printed 1 - progress messages are printed (percent complete) 2 - all module messages are printed 3 - additional verbose messages are printed This variable is automatically created by g.parser so that the --verbose or --quiet flags will be inherited by dependent modules as the script runs. What is still unclear to me: Setting the --quiet flag in a script using g.parser (what I am doing) automatically sets the GRASS_VERBOSE variable to 1? --quiet should set it to 0 (actually to MINLEVEL, but that is defined as 0 in lib/gis/verbose.c). I can confirm that: r.stats elevation -c gives me the percent complete info. r.stats elevation -c --quiet doesn't. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] osgeo4w-wingrass 7 broken
Hi, 2013/3/21 Martin Landa landa.mar...@gmail.com: checking whether to use regex... yes checking for location of regex includes... checking for regex.h... no configure: error: *** Unable to locate regex includes. just some local mess, builds should be back (no. 528). Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI spin control for floating point ???
I agree that spinner can be nice in some situations, but are more of a pain in others, and can even decrease functionality because they limit the precision and range of values that can be entered into a control (sometimes good and sometimes not). Nothing wrong with typing a number if great flexibility is needed. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Mar 21, 2013, at 5:12 AM, grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org wrote: From: Martin Landa landa.mar...@gmail.commailto:landa.mar...@gmail.com Subject: Re: [GRASS-dev] wxGUI spin control for floating point ??? Date: March 21, 2013 5:11:59 AM MST To: Markus Metz markus.metz.gisw...@gmail.commailto:markus.metz.gisw...@gmail.com Cc: GRASS developers list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org Hi, 2013/3/21 Markus Metz markus.metz.gisw...@gmail.commailto:markus.metz.gisw...@gmail.com: What is the reason to have a spin control for floating point values? Could the spin control at least not use the number but the significant digits (same like printing with %g) for spinning? E.g. for 0.0001 I see 0.000 which is wrong. IMHO the spin control should be reverted to text input. sometimes float spin controls are useful sometimes not. Useful eg. `d.vect size`, but not for the case you mentioned. Probably we could stay with floating spin control (some improvements required) rather than plain text input. No strong opinion here. Martin -- Martin Landa landa.martin gmail.comhttp://gmail.com/ * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
kapo coulibaly wrote: How about sticking with shell? Using the shell frequently results in scripts which don't work reliably on Unix or at all on Windows. It's also a horrible language for anything beyond the simplest tasks. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.sun.angle to replace i.sunhours in trunk
On Thu, Mar 14, 2013 at 7:06 AM, Yann Chemin yann.che...@gmail.com wrote: r.sun.angle has the same functionality as i.sunhours + additional functionality, it would be good to remove i.sunhours from trunk and bring r.sun.angle in trunk. If there are no objections, I can do that (svn copy). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
Anna Kratochvílová wrote: PS - There is a similar problem with Python version (required 2.4). Some interesting features start with 2.5 but usually we can live without it. Any opinions? I see no reason to support 2.4, and at least one reason to require at least 2.5 (the with statement). Requiring 2.6 would allow us to start work on forward compatibility with Python 3.x. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI spin control for floating point ???
On Thu, Mar 21, 2013 at 8:53 PM, Anna Kratochvílová kratocha...@gmail.com wrote: On Thu, Mar 21, 2013 at 1:11 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2013/3/21 Markus Metz markus.metz.gisw...@gmail.com: What is the reason to have a spin control for floating point values? Could the spin control at least not use the number but the significant digits (same like printing with %g) for spinning? E.g. for 0.0001 I see 0.000 which is wrong. IMHO the spin control should be reverted to text input. sometimes float spin controls are useful sometimes not. Useful eg. `d.vect size`, but not for the case you mentioned. Probably we could stay with floating spin control (some improvements required) rather than plain text input. No strong opinion here. Because we don't know the meaningful number of digits, I agree to use text input. Changing the float spin might be too much work and I think it is not worth it. I have changed it in r55484. Thanks! That means we can change the r.terraflow default for d8cut back to infinity which is a valid number (#1888)? Markus M Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
Regarding r55461: MATH_LIBS=$MATH_LIBS -lbsd What's the point of this? That variable isn't substituted. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1757: LD_SEARCH_FLAGS incorrect for NetBSD
#1757: LD_SEARCH_FLAGS incorrect for NetBSD
-+--
Reporter: brook| Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: |Platform: Other Unix
Cpu: Unspecified |
-+--
Comment(by mmetz):
Replying to [comment:4 glynn]:
Replying to [comment:3 mmetz]:
Replying to [comment:2 glynn]:
7.0 doesn't support any BSD systems yet. New platforms need to be
added by people who actually have access to (and preferably knowledge of)
the platform in question.
However, I do not get 7.0 compiled on NetBSD 6.0.1, the error is
{{{
ld: unrecognized option '-Wl,-rpath,/home/metz/src/grass-7.0.svn/dist.i386
-unknown-netbsdelf6.0.1/lib'
}}}
Do NetBSD shared libraries support rpath? If not, the linker probably
won't accept the switch.
Yes, NetBSD shared libraries support rpath.
Also, -rpath is bad, as it hard-codes library paths, overriding
LD_LIBRARY_PATH (and it will probably result in hard-coding the build
directory into the installed binaries). -rpath-link is preferable, as that
just sets the path for dependency checking without storing it in the
binary.
NetBSD is a bit difficult, I have to check. Some more insights from
working with NetBSD:
I think I discovered inconsistencies, if not errors, in the G7 Make
system: flags meant for cc are also passed to ld and vice versa, probably
because it is assumed that ld = cc. For example, linking flags for cc must
have the form
{{{
-Wl,-rpath,${LIB_RUNTIME_DIR}
}}}
the equivalent to ld, if ld != cc, is
{{{
-rpath ${LIB_RUNTIME_DIR}
}}}
But Shlib.make does
{{{
LDFLAGS += $(SHLIB_LDFLAGS)
}}}
even though LDFLAGS are meant for cc and SHLIB_LDFLAGS are meant for ld,
at least aclocal.m4 says so. Shlib.make might also need LD_SEARCH_FLAGS.
Grass.make does
{{{
LDFLAGS = $(LIBPATH) $(LINK_FLAGS) $(LD_SEARCH_FLAGS)
}}}
even though LDFLAGS are meant for cc and LD_SEARCH_FLAGS are meant for ld,
at least aclocal.m4 says so.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1757#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI spin control for floating point ???
On Thu, Mar 21, 2013 at 9:15 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Thu, Mar 21, 2013 at 8:53 PM, Anna Kratochvílová
kratocha...@gmail.com wrote:
On Thu, Mar 21, 2013 at 1:11 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/3/21 Markus Metz markus.metz.gisw...@gmail.com:
What is the reason to have a spin control for floating point values?
Could the spin control at least not use the number but the significant
digits (same like printing with %g) for spinning? E.g. for 0.0001
I see 0.000 which is wrong. IMHO the spin control should be reverted
to text input.
sometimes float spin controls are useful sometimes not. Useful eg.
`d.vect size`, but not for the case you mentioned. Probably we could
stay with floating spin control (some improvements required) rather
than plain text input. No strong opinion here.
Because we don't know the meaningful number of digits, I agree to use
text input. Changing the float spin might be too much work and I think
it is not worth it. I have changed it in r55484.
Thanks! That means we can change the r.terraflow default for d8cut
back to infinity which is a valid number (#1888)?
Hm, not sure about that, there is a validator in the textCtrl to check
for float values...
[testing]
Ok, if you use 'inf' as a default answer it should work because
float('inf') is a valid expression in Python.
But there was 'infinity', so if you insist on 'infinity', some
conversion must be done in forms.py before setting the value.
Anna
Markus M
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1757: LD_SEARCH_FLAGS incorrect for NetBSD
#1757: LD_SEARCH_FLAGS incorrect for NetBSD -+-- Reporter: brook| Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: |Platform: Other Unix Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:5 mmetz]: I think I discovered inconsistencies, if not errors, in the G7 Make system: flags meant for cc are also passed to ld and vice versa, probably because it is assumed that ld = cc. Programs written in C are linked with $(CC). Programs written in C++ are linked with $(CXX). Shared libraries are linked with $(SHLIB_LD). All three are passed $(LDFLAGS). $(SHLIB_LD) is additionally passed $(SHLIB_LDFLAGS). In practical terms, this requires that both programs and shared libraries are linked using the compiler front-end. The build system doesn't use $(LD) (which is normally the underlying linker). The main problem with separating the two is that configure doesn't attempt to maintain any distinction, e.g. it only has one LDFLAGS variable. Simlarly, pkg-config --libs ... will generate switches suitable for passing to the compiler (i.e. with the -Wl, prefix). -- Ticket URL: https://trac.osgeo.org/grass/ticket/1757#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
Hi, I gained back access to an older AIX 5.3 system and try to compile GRASS 7.svn: /afs/cluster/myuser/private/software/grass-7.0.svn/lib/gis make xlc_r -DANSI -I/afs/cluster/software/vni/CTT6.0/include -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -DGRASS_VERSION_DATE=\'2013'\ -DPACKAGE=\grasslibs\ -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -o OBJ.powerpc-ibm-aix5.3.0.0/plot.o -c plot.c plot.c, line 34.15: 1506-343 (S) Redeclaration of nearest differs from previous declaration on line 941 of /usr/include/math.h. plot.c, line 34.15: 1506-376 (I) Redeclaration of nearest has a different number of fixed parameters than the previous declaration. make: *** [OBJ.powerpc-ibm-aix5.3.0.0/plot.o] Error 1 (Note the AIX xlc compiler) Meanwhile I'll try the gcc compiler. markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
On Fri, Mar 22, 2013 at 12:11 AM, Markus Neteler nete...@osgeo.org wrote: Hi, I gained back access to an older AIX 5.3 system and try to compile GRASS 7.svn: /afs/cluster/myuser/private/software/grass-7.0.svn/lib/gis make xlc_r -DANSI -I/afs/cluster/software/vni/CTT6.0/include -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -DGRASS_VERSION_DATE=\'2013'\ -DPACKAGE=\grasslibs\ -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -I/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/include -o OBJ.powerpc-ibm-aix5.3.0.0/plot.o -c plot.c plot.c, line 34.15: 1506-343 (S) Redeclaration of nearest differs from previous declaration on line 941 of /usr/include/math.h. plot.c, line 34.15: 1506-376 (I) Redeclaration of nearest has a different number of fixed parameters than the previous declaration. make: *** [OBJ.powerpc-ibm-aix5.3.0.0/plot.o] Error 1 (Note the AIX xlc compiler) Meanwhile I'll try the gcc compiler. Happens as well with gcc. I locally renamed the variable (yet to be fixed properly in SVN). Next problem: grass-7.0.svn/lib/datetime make o /afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/lib/libgrass_datetime.7.0.svn.so -L/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/lib -L/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/lib -L/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/lib OBJ.powerpc-ibm-aix5.3.0.0/between.o OBJ.powerpc-ibm-aix5.3.0.0/change.o OBJ.powerpc-ibm-aix5.3.0.0/copy.o OBJ.powerpc-ibm-aix5.3.0.0/diff.o OBJ.powerpc-ibm-aix5.3.0.0/error.o OBJ.powerpc-ibm-aix5.3.0.0/format.o OBJ.powerpc-ibm-aix5.3.0.0/incr1.o OBJ.powerpc-ibm-aix5.3.0.0/incr2.o OBJ.powerpc-ibm-aix5.3.0.0/incr3.o OBJ.powerpc-ibm-aix5.3.0.0/local.o OBJ.powerpc-ibm-aix5.3.0.0/misc.o OBJ.powerpc-ibm-aix5.3.0.0/same.o OBJ.powerpc-ibm-aix5.3.0.0/scan.o OBJ.powerpc-ibm-aix5.3.0.0/sign.o OBJ.powerpc-ibm-aix5.3.0.0/type.o OBJ.powerpc-ibm-aix5.3.0.0/tz1.o OBJ.powerpc-ibm-aix5.3.0.0/tz2.o OBJ.powerpc-ibm-aix5.3.0.0/values.o -lm make: o: Command not found We had this also with MingW, the fix was http://trac.osgeo.org/grass/changeset/54352 Actually I don't see how to fix the junk char (or whatever causes this o). markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
Markus Neteler wrote: I gained back access to an older AIX 5.3 system and try to compile GRASS 7.svn: plot.c, line 34.15: 1506-343 (S) Redeclaration of nearest differs from previous declaration on line 941 of /usr/include/math.h. Meanwhile I'll try the gcc compiler. The issue is with the standard C library, so changing the compiler probably won't help. Happens as well with gcc. I locally renamed the variable (yet to be fixed properly in SVN). First, check: line 941 of /usr/include/math.h It may be that the declaration is protected by a #ifdef and can be deactivated with the appropriate switch. Next problem: grass-7.0.svn/lib/datetime make o /afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/lib/libgrass_datetime.7.0.svn.so make: o: Command not found This suggests that SHLIB_LD is empty, so the command: $(SHLIB_LD) -o $@ $(LDFLAGS) $^ $(LIBES) $(EXTRA_LIBS) $(MATHLIB) reduces to: -o $@ $(LDFLAGS) $^ $(LIBES) $(EXTRA_LIBS) $(MATHLIB) A leading dash is interpreted by make as a flag which causes errors to be ignored. So it interprets the o as the name of the program. And indeed, the *aix* section in SC_CONFIG_CFLAGS doesn't define SHLIB_LD, so you'll need to use --disable-shared. Ideally, AC_MSG_ERROR should be called if shared libraries are requested for a platform which doesn't have support for them. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
