Re: [GRASS-dev] [GRASS GIS] #3273: Fails to build with GCC 7

2017-08-04 Thread GRASS GIS 
#3273: Fails to build with GCC 7
-+-
  Reporter:  Bas Couwenberg  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.2
 Component:  Compiling   |Version:  7.2.0
Resolution:  |   Keywords:
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by Bas Couwenberg):

 GCC 7 is now the default compiler in Debian causing the issue to become
 Release Critical which will trigger to automatic removal of the package
 from Debian testing (and by extension from the next stable release) when
 the issue remains unfixed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Michael Barton 
This made a big difference.

By setting:

export LD_LIBRARY_PATH="/Applications/anaconda/lib:$LD_LIBRARY_PATH

in my terminal before configure, I could successfully build GRASS with all 
dependencies in anaconda except FreeType and Cairo.

I tried linking in the --with-cairo-ldflags argument

--with-cairo-ldflags="-lcairo -L$/Applications/anaconda/lib -liconv"

This still gave an error on building, but a different from the clang one.

In file included from text.c:19:
/Applications/anaconda/include/cairo/cairo-ft.h:50:10: fatal error:
  'fontconfig/fontconfig.h' file not found
#include 

It should be searching in /Applications/anaconda/include/fontconfig

This is definitely closer.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Aug 4, 2017, at 3:50 PM, Eric Hutton 
> wrote:

Hi Michael

I found that if I manually add linker flags (like "-L$PREFIX/lib -liconv") I 
was able to get rid of these errors. I also notice that I had to append them to 
the end of the compile command (or at least after things like 
"-lgrass_gis.7.2.0" - I guess it has to do with the order that the compiler 
looks at libraries to resolve sysbols). Then, at runtime $PREFIX/lib needed to 
appear in the LD_LIBRARY_PATH_VAR when running the tests.

I'm not sure of the best way to fix this within the grass build system (simply 
adding the link flags to LDFLAGS didn't do the trick). Perhaps tweaking 
Rules.make and the like would do the trick? I think the basic problem is that 
conda does the entire build within a temporary folder that contains 
installations of all the dependencies and that this temporary folder is not 
added to all the necessary places.

Eric


On Fri, Aug 4, 2017 at 3:05 PM Michael Barton 
> wrote:
After a tedious set of tests, I can say that GRASS will not build with ANY 
dependency from Anaconda except SQLite. That is, I went through the 
dependencies one-by-one and replaced the path to a Framework version with an 
Anaconda version in my configure string. I did a make clean between each build 
attempt.

All the versions are close (secondary or tertiary version number) or identical 
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot 
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
  Reason: image not found

It seems to me like there has to be some kind of systematic reason for this not 
to work. Something hardwired in a key makefile or something. The Anaconda 
packages are all current builds of normal dependencies.

I am even doing it in an environment in which /Applications/anaconda/bin is 
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 
480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  
480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton,
 
http://csdc.asu.edu















On Aug 4, 2017, at 12:56 AM, Moritz Lennert 
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I paths and see if you need to set 
one of these differently or add additional one for iconv. I don't see how

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Michael Barton 
I'm very glad you've found a way forward. Perhaps someone else on this thread 
can suggest how it might be incorporated into the GRASS build system. I have 
several questions below, that are a result of my spotty understanding (or 
ignorance) of the details of build systems.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu


On Aug 4, 2017, at 3:50 PM, Eric Hutton 
> wrote:

Hi Michael

I found that if I manually add linker flags (like "-L$PREFIX/lib -liconv") I 
was able to get rid of these errors.

Where do you add these? In every GRASS module? Or someplace more general?

I also notice that I had to append them to the end of the compile command (or 
at least after things like "-lgrass_gis.7.2.0" - I guess it has to do with the 
order that the compiler looks at libraries to resolve sysbols).

Again, where does this go?

Then, at runtime $PREFIX/lib needed to appear in the LD_LIBRARY_PATH_VAR when 
running the tests.

Can I just add this to my .profile or run this the shell I've opened to compile 
GRASS prior to configure?


I'm not sure of the best way to fix this within the grass build system (simply 
adding the link flags to LDFLAGS didn't do the trick). Perhaps tweaking 
Rules.make and the like would do the trick? I think the basic problem is that 
conda does the entire build within a temporary folder that contains 
installations of all the dependencies and that this temporary folder is not 
added to all the necessary places.

When you say that "conda does the entire build...", are you referring to 
building/installing the dependencies? Or are you referring to building GRASS? 
So far, I've been trying to build GRASS from the shell, like I've done it 
before, but giving the conda paths to dependencies instead of 
/System/Frameworks/...

Michael


Eric


On Fri, Aug 4, 2017 at 3:05 PM Michael Barton 
> wrote:
After a tedious set of tests, I can say that GRASS will not build with ANY 
dependency from Anaconda except SQLite. That is, I went through the 
dependencies one-by-one and replaced the path to a Framework version with an 
Anaconda version in my configure string. I did a make clean between each build 
attempt.

All the versions are close (secondary or tertiary version number) or identical 
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot 
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
  Reason: image not found

It seems to me like there has to be some kind of systematic reason for this not 
to work. Something hardwired in a key makefile or something. The Anaconda 
packages are all current builds of normal dependencies.

I am even doing it in an environment in which /Applications/anaconda/bin is 
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 
480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  
480-727-0709 (CSDC)
www: 
http://www.public.asu.edu/~cmbarton,
 
http://csdc.asu.edu















On Aug 4, 2017, at 12:56 AM, Moritz Lennert 
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Michael Barton 
After a tedious set of tests, I can say that GRASS will not build with ANY 
dependency from Anaconda except SQLite. That is, I went through the 
dependencies one-by-one and replaced the path to a Framework version with an 
Anaconda version in my configure string. I did a make clean between each build 
attempt.

All the versions are close (secondary or tertiary version number) or identical 
between William's framework builds and those in Anaconda.

For FreeType and Cairo, the errors of the type I posted yesterday

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

For the other dependencies, the errors are that the appropriate library cannot 
be found, like the following for fftw:

dyld: Library not loaded: @rpath/libfftw3.3.dylib
  Referenced from: 
/Users/cmbarton/grass_source/trunk/dist.x86_64-apple-darwin16.7.0/lib/libgrass_gmath.7.3.svn.dylib
  Reason: image not found

It seems to me like there has to be some kind of systematic reason for this not 
to work. Something hardwired in a key makefile or something. The Anaconda 
packages are all current builds of normal dependencies.

I am even doing it in an environment in which /Applications/anaconda/bin is 
first in my PATH (which works fine if the dependencies are Frameworks).

Any thoughts on this?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Aug 4, 2017, at 12:56 AM, Moritz Lennert 
> wrote:

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I paths and see if you need to set 
one of these differently or add additional one for iconv. I don't see how to 
set this through ./configure (I don't see any --with-iconv-includes= or 
--with-iconv-libs=), but you can start by editing the Makefiles or the command 
itself and changing -L and -I directly.
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  _draw_main in text3.o
  "_iconv_close", referenced from:
  _draw_main in text3.o
  "_iconv_open", referenced from:
  _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Just guessing: Could the error be linked to the use of clang ? Have you tried 
with gcc ?

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] openMP support in GRASS GIS

2017-08-04 Thread Moritz Lennert 

Thanks Maris,

[BTW: your mail was sent only to me, so I'm forwarding to the list.]

On 04/08/17 16:04, Maris Nartiss wrote:

1. It is not a dependency, as OpenMP code should run just fine also
when compiled without OpenMP. Those are just comments in code thus
backwards safe.


Right. I now see that all code is conditionalized on _OPENMP being set 
and I suppose that happens when you use --with-openmp as a compiler switch ?



2. It is not as easy as it seems, as every place, where
parallelisation is introduced, needs to be examined carefully to not
introduce hard to track issues when common variables are changed and
to not make even worse performance by making CPU cache dirty when it
isn't. Of course these problems affect only binaries compiled with
OpenMP. Thus OpenMP support in GRASS GIS could be marked as "use at
own risk".



This thus means that merging the OpenMP version into the trunk version 
will not have any consequences for the "normal" user. However, does it 
mean that maintenance of the modules will become more complex ?


I see that in v.surf.rst the OpenMP stuff has already been integrated. 
It's only been 7 months, but up to now noone has complained, so I think 
we could integrate openmp into the two other modules as well (r.sun + 
r.sim.water).


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] openMP support in GRASS GIS

2017-08-04 Thread Moritz Lennert 

On 04/08/17 12:35, Markus Neteler wrote:

Hi,

just saw that this article got published (congrats, Jaro and team):

Hofierka, J., Lacko, M., Zubal, S., 2017. Parallelization of
interpolation, solar radiation and water flow simulation modules in
GRASS GIS using OpenMP. Computers & Geosciences.
doi:10.1016/j.cageo.2017.07.007

Questions: since the code is already in addons, how about merging the
changes into trunk?


I'm no expert on OpenMP. I imagine it is integrated at compile time ? 
does this mean that openmp will become a dependency of GRASS GIS ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] openMP support in GRASS GIS

2017-08-04 Thread Markus Neteler 
Hi,

just saw that this article got published (congrats, Jaro and team):

Hofierka, J., Lacko, M., Zubal, S., 2017. Parallelization of
interpolation, solar radiation and water flow simulation modules in
GRASS GIS using OpenMP. Computers & Geosciences.
doi:10.1016/j.cageo.2017.07.007

Questions: since the code is already in addons, how about merging the
changes into trunk?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OGR SQLite question

2017-08-04 Thread Moritz Lennert 

On 04/08/17 11:56, Markus Neteler wrote:

On Fri, Aug 4, 2017 at 11:51 AM, Moritz Lennert
 wrote:

On 29/07/17 17:59, Michael Barton wrote:


The db.out.ogr manual states for the input argument:

input=name [required]
GRASS table name
Or data source for direct OGR access

How do you specify the name of a table in the GRASS sqlite.db that is not
linked to vector objects?



Probably the manual could do with an update to reflect the fact that it only
works for existing maps. Maybe the input parameter should be renamed to
'map' ?


IMHO no - it refers to a *table*, not a map (the db.* commands have
generally no idea about maps but only about tables).


But internally, it uses v.out.ogr with input=input, and input in 
v.out.ogr is defined as


options->input = G_define_standard_option(G_OPT_V_INPUT);

So it is a map. This is why you get:

g.copy vect=schools_wake,schools
v.distance -a from=schools to=schools table=distances_between_schools 
up=cat,dist col=tocat,dist output=lines

db.out.ogr distances_between_schools output=distances_between_schools.csv
ERROR: Vector map  not found
ERROR: Module  failed

If we want to make db.out.ogr into a module to export any table to any 
ogr compatible formats, we would probably have to use ogr2ogr within the 
script (or the gdal python API).


I don't know how often people really need to transform tables into 
something else than csv files. Personally, I find db.select more than 
enough to move data from one database to another:


db.select table=distances_between_schools sep=, 
out=distances_between_schools.csv


(or with the sql parameter if you want to select specific columns only).

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.2

2017-08-04 Thread Martin Landa 
2017-08-04 11:37 GMT+02:00 Markus Neteler :
> r71253 dbmi_base lib: add missing arg type
> r71191 lidarlib: free structs
>
> They are not backport yet in case they should be.

I think so, done in r71323-4. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OGR SQLite question

2017-08-04 Thread Markus Neteler 
On Fri, Aug 4, 2017 at 11:51 AM, Moritz Lennert
 wrote:
> On 29/07/17 17:59, Michael Barton wrote:
>>
>> The db.out.ogr manual states for the input argument:
>>
>> input=name [required]
>> GRASS table name
>> Or data source for direct OGR access
>>
>> How do you specify the name of a table in the GRASS sqlite.db that is not
>> linked to vector objects?
>
>
> Probably the manual could do with an update to reflect the fact that it only
> works for existing maps. Maybe the input parameter should be renamed to
> 'map' ?

IMHO no - it refers to a *table*, not a map (the db.* commands have
generally no idea about maps but only about tables).

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

2017-08-04 Thread GRASS GIS 
#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Default  |Version:  7.2.0
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by neteler):

 Replying to [comment:17 lbartoletti]:
 > The most changes to the sources is to replace hardcoded python to the
 specific version used.

 @devs: do we want this upstream?

 https://svnweb.freebsd.org/ports/head/databases/grass7/Makefile?view=markup

 > You can see all changes on
 [https://svnweb.freebsd.org/ports/head/databases/grass7/Makefile?view=markup
 Makefile] and
 [https://svnweb.freebsd.org/ports/head/databases/grass7/files/ patches]

 I see specifically these patches:

 # test writable check change

 https://svnweb.freebsd.org/ports/head/databases/grass7/files/patch-
 include_Make_Install.make?view=markup

 # ctypes GCC flag change:

 https://svnweb.freebsd.org/ports/head/databases/grass7/files/patch-
 lib_python_ctypes_ctypesgencore_parser_preprocessor.py?view=markup

 but I am not sure if to be updated in G7 or not - any dev having a
 suggestion?

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OGR SQLite question

2017-08-04 Thread Moritz Lennert 

On 29/07/17 17:59, Michael Barton wrote:

The db.out.ogr manual states for the input argument:

input=name [required]
GRASS table name
Or data source for direct OGR access

How do you specify the name of a table in the GRASS sqlite.db that is 
not linked to vector objects?


Probably the manual could do with an update to reflect the fact that it 
only works for existing maps. Maybe the input parameter should be 
renamed to 'map' ?


I'd like to export the distance matrix 
table created with v.distance -a.


Either do as Markus suggests (i.e. directly output the v.distance 
results to a file), or you can use db.select to extract the info you need:


db.select "select col1, col2, col3 from NameOfTable" 
output=YourDesiredOutputFile



Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3091: The RUN_GISBASE variable is not set correctly on FreeBSD

2017-08-04 Thread GRASS GIS 
#3091: The RUN_GISBASE variable is not set correctly on FreeBSD
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Default  |Version:  7.0.4
Resolution:  fixed|   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  7.0.6 => 7.2.2


Comment:

 Replying to [comment:5 lbartoletti]:
 > Hi,
 >
 > You can close this tickets, we have
 [https://trac.osgeo.org/grass/ticket/2940 patched files] for FreeBSD.

 ... solved in #2940, closing.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.2

2017-08-04 Thread Markus Neteler 
Hi,

what about these fixes here done by mmetz?

r71253 dbmi_base lib: add missing arg type
r71191 lidarlib: free structs

They are not backport yet in case they should be.

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OGR SQLite question

2017-08-04 Thread Markus Neteler 
On Sat, Jul 29, 2017 at 5:59 PM, Michael Barton  wrote:
[ ...]
> I'd like to export the distance matrix table
> created with v.distance -a.

You could redirect it to a file (of course a "file=" parameter would
be more elegant):

# test case, NC dataset
v.extract input=hospitals output=hospitals_test where="COUNTY='Swayne'
OR COUNTY = 'Watauga' OR COUNTY = 'Mecklenburg'"

# reduced dataset for test purpose
v.db.select hospitals_test -c  | wc -l
13

# distance matrix, incl direct export to file
v.distance -pa from=hospitals_test to=hospitals_test upload=dist
separator=comma  > matrix.csv

# verification:
cat matrix.csv
from_cat,to_cat,dist
 ,3,30,31,32,33,34,35,36,112,113,144,153,158
3,0,133276.42086464912,133041.35107619612,141872.64495940649,132555.12137443203,146710.29481383949,132452.46169504456,132808.38654187109,132674.02650356843,135717.81027315429,128054.31107769182,133073.02636643461,8321.7239556961049
30,133276.42086464912,0,566.10649525099063,14086.796281187319,938.12265075535947,13680.491183464996,1228.7359334346045,810.6623841657422,2198.585588861451,2465.1333840697835,13866.283103129103,1122.5705627816278,128211.04370485671
[...]

Best
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.segment: possible to cache results of open_files() for several runs of i.segment ?

2017-08-04 Thread Moritz Lennert 

On 03/08/17 14:09, Markus Metz wrote:
There is one relatively easy possibility to speed up reading input, if 
the input maps are compressed with ZLIB or BZIP2: you could compress the 
input maps with LZ4, this would speed up reading since quite a bit of 
time is spent on decompressing ZLIB or BZIP2 compressed data.


export GRASS_COMPRESSOR=LZ4
r.compress 


Thanks for the info ! We'll test that as well as trying out different 
solutions combining classical hard disk, ssd and possibly ram disk, 
especially for running many i.segment instances in parallel on the same 
data.


Moritz



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New attempt to update GRASS for Mac

2017-08-04 Thread Moritz Lennert 

On 04/08/17 00:33, Vaclav Petras wrote:
Well, the error (below) suggests that wrong library is either linked or 
included. You need to go through the -L and -I paths and see if you need 
to set one of these differently or add additional one for iconv. I don't 
see how to set this through ./configure (I don't see any 
--with-iconv-includes= or --with-iconv-libs=), but you can start by 
editing the Makefiles or the command itself and changing -L and -I directly.



Undefined symbols for architecture x86_64:
   "_iconv", referenced from:
   _draw_main in text3.o
   "_iconv_close", referenced from:
   _draw_main in text3.o
   "_iconv_open", referenced from:
   _draw_main in text3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)




Just guessing: Could the error be linked to the use of clang ? Have you 
tried with gcc ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev