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 <fontconfig/fontconfig.h>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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<tel:(480)%20965-6262> (SHESC),
480-965-8130<tel:(480)%20965-8130>/727-9746 (CSDC)
fax: 480-965-7671<tel:(480)%20965-7671> (SHESC),
480-727-0709<tel:(480)%20727-0709> (CSDC)
www:
http://www.public.asu.edu/~cmbarton<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=KtrgOgv-4RMiEJEdKKQg5Z_ZL4pv8gJw3U0lH7fV_jg&s=LIHaJSGN6aEh018lfLuD_oohvcwC4GRCW2pleRj90HE&e=>,
http://csdc.asu.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=KtrgOgv-4RMiEJEdKKQg5Z_ZL4pv8gJw3U0lH7fV_jg&s=ZZ_j-P8_GLz4WT29WIipvPXFuAZoZlYUntcjvNtYEOs&e=>
On Aug 4, 2017, at 12:56 AM, Moritz Lennert
<[email protected]<mailto:[email protected]>> 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
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
