I just tried this patch and it made no difference.
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 Universi
Markus and Eric,
I have not had a chance to try these things out because of the chaos of the
beginning of semester. That's why I'd hoped to get further along when in
Boulder. Once things calm down next week (I hope), I'll try these out.
Michael
C. Michael Barton
Director, C
Hi Michael,
On Wed, Aug 16, 2017 at 12:10 AM, Eric Hutton wrote:
> Hi Michael
>
> It's hard for me to say without seeing which tests are failing but I think
> at least some of those errors are probably due to DYLD_LIBRARY_PATH not
> being set correctly. As far as I can tell, when grass is being t
Very frustrating.
I can no longer get GRASS 7.2 or trunk to compile using anaconda dependencies,
even without cairo or freetype. I have tried everything I can think of but
cannot get it to compile like it did last week. Perhaps someone can offer
advice.
I have errors in all or nearly all of th
Does setting
--enable-shared
in configure make any difference for Mac compiling?
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 System
Fixed the nviz/3D issue by resetting GRASS_PYTHON to
/Applications/anaconda/bin/pythonw
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
I have built both GRASS 7.3 and 7.2svn without errors using Anaconda
dependencies if I configure --without-cairo and --without-freetype.
When I install GRASS and launch it, first it hangs and time outs at
Rebuilding Addon HTML manual pages index...
Rebuilding Addon menu...
Then the GUI crashes
>checking for cairo.h... yes
>Package cairo was not found in the pkg-config search path.
>Perhaps you should add the directory containing `cairo.pc'
>to the PKG_CONFIG_PATH environment variable
>No package 'cairo' found
>checking for location of cairo library..
Does the suggestion?
-
best
To GRASS devs:
When I configure with paths to anaconda cairo and freetype dependencies, I get
no errors (see below).
But when I check the configure.log, I see the same error I'm getting at the end
of a failed build:
Undefined symbols for architecture x86_64:
"_iconv", referenced from:
I figured you are working towards an anaconda build. I'm trying something
simpler. What did you change in platform.make?
Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University
...Sent from my iPad
On Aug 5, 2017, at 11:05 AM, Eri
Is the place to fix this in ../include/make/Platform.make?
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
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
--wit
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
__
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 bui
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 ./configu
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=
o
Here is a little bit from one of the discussions on an error like we have
reported:
-
Usually the programmer hasn't observed case-sensitivity or something wasn't
added to the target.
The error is issued by the linker (ld) because it can't resolve a reference to
a symbol.
-
MIchael
_
Understood.
Currently, we very much need new Mac binaries. So in this case, I think it will
be more useful to find out how to fix this on the Mac and then get on a Linux
box and generalize it for Anaconda, so it can be even more widely available.
So I'm hoping for some input on this error if an
On Thu, Aug 3, 2017 at 4:23 PM, Michael Barton
wrote:
>
> Doing this in Docker is another step after we work this out. One step at a
> time.
>
> The goal at the moment is to do this on and for the Mac. So we might or
> might not get the same results on Linux, but it would not be relevant to
> iss
Thanks Vaclav,
Doing this in Docker is another step after we work this out. One step at a time.
The goal at the moment is to do this on and for the Mac. So we might or might
not get the same results on Linux, but it would not be relevant to issues on
the Mac.
Michael
C. Mi
On Thu, Aug 3, 2017 at 3:39 PM, Michael Barton
wrote:
> Working with a very helpful software engineer at CSDMS here in Boulder,
> we've decided that a good way to work out a new and more sustainable way to
> create binaries would be to compile GRASS under Anaconda. We could then
> more easily pac
Working with a very helpful software engineer at CSDMS here in Boulder, we've
decided that a good way to work out a new and more sustainable way to create
binaries would be to compile GRASS under Anaconda. We could then more easily
package GRASS and all dependencies, and subsequently make it int
Yeah, it doesn't really look at wxpython at runtime, it's (GRASS_WX64BIT)
hardwired from compilation.
GRASS_WXBUNDLED is (was? maybe it's been stripped out?) meant to tell the GUI
code somewhere that wxpython is bundled, there was a problem where wxpython
wouldn't work, maybe it's fixed now. G
A bit more information.
The grass.sh.in script tries to find a pythonw file to use for Python. It
checks the setting of GRASS_PYTHON, then it looks in standard places for system
Python.
The script also seems to set GRASS_PYTHONWX to the value of GRASS_PYTHON after
it searches for a useable Pyt
I was able to track this down.
I was setting GRASS_PYTHON to ../anaconda/bin/python
The grass.sh.in script for Mac OS is set up to only accept "pythonw" for the
path to python, not "python".
Once I changed my .profile to include the line:
export GRASS_PYTHON="/Applications/anaconda/bin/python"
Hi William,
That would indeed be useful, especially to make sure a specific version of
Python and wxPython are used. But it doesn't seem to do anything. Does anyone
know if this is used anywhere?
Related to this, is there a way to set the Python used at launch?
Michael
C.
Here is the error and its cause
From the GRASS terminal, I set the environment so that it defaults to Anaconda
Python and wxPython (the environment of compilation).
GRASS 7.3.svn (nc_spm_08_grass7):~ > export
PATH="/Applications/anaconda/bin:$PATH"
Test the environment.
GRASS 7.3.svn (nc_spm
I think the intent was to be able to customize python and pythonw separately,
if only to have that possibility, I don't remember if there was a specific
reason.
> On Jul 28, 2017, at 3:13 PM, Michael Barton wrote:
>
> I had to hack python_wrapper to the following:
>
> if [ -z "$GISBASE" ] ; t
I had to hack python_wrapper to the following:
if [ -z "$GISBASE" ] ; then
echo "You must be in GRASS GIS to run this program." >&2
exit 1
fi
SYSARCH=`uname -p`
SYSVER=`uname -r | cut -d . -f 1`
if [ ! "$GRASS_PYTHONWX" ] ; then
GRASS_PYTHONWX="pythonw"
fi
exec "$GRASS_PYTHONWX" "$@"
On Fri, Jul 28, 2017 at 3:49 PM, Michael Barton
wrote:
>
> Set up and activated virtual environment in conda
> Ensured that Anaconda Python is default
> Ensured that Anaconda wxPython 4 is default
> Compiled GRASS trunk in this environment
> Launched the app created and...
>
> Launching GUI in t
Maybe it's the python wrapper - it does 2 things: force python to run 32bit if
wxpython is 32bit, and run pythonw that wxpython needs. There is a 2nd env var
to set pythonw (I think it's only used here): GRASS_PYTHONWX.
> On Jul 28, 2017, at 2:49 PM, Michael Barton wrote:
>
> ARGGH!
>
> Set
ARGGH!
Set up and activated virtual environment in conda
Ensured that Anaconda Python is default
Ensured that Anaconda wxPython 4 is default
Compiled GRASS trunk in this environment
Launched the app created and...
Launching GUI in the background, please wait...
GRASS 7.3.svn (nc_spm_08_grass7):~
Most Mac users are running from the GUI and will not be trying to set an
environmental variable from the terminal before running a command from the
terminal. We need to be thinking like most Mac users.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexi
Previously, we needed to set this path to compile GRASS so that it worked with
wxPython wrappers for wxWidgets. I will do a new compile without this argument
and see what happens.
In any case, I need to be able to make sure that GRASS uses the wxPython that
is bundled with it by default to avoi
Sorry if my message was not clear Moritz.
I showed the output of a non-GRASS terminal window, just to show that the
GRASS_PYTHON environmental variable was indeed set. I set it in .profile,
sourced .profile, and then launched GRASS because GRASS looks for Python when
it launches (or at least th
On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton
wrote:
>
> The other issue I'm hitting is that the configure argument to enable
wxPython, '-with-wxwidgets=' expects a path to a wx_config file. AFAICT,
wxPython 4 does not have such a file. And I can't yet find anything that
seems to serve the same
On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton
wrote:
> OK. I'll put it into my .profile and see what happens. Thanks.
On Fri, Jul 28, 2017 at 12:19 AM, Michael Barton
wrote:
>
> Tried that and it seems to be ignored too. Here is the output from a
terminal in the shell (outside GRASS):
>
> Las
On 28/07/17 06:19, Michael Barton wrote:
Tried that and it seems to be ignored too. Here is the output from a
terminal in the shell (outside GRASS):
Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python
This should make anac
Tried that and it seems to be ignored too. Here is the output from a terminal
in the shell (outside GRASS):
Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python
This should make anaconda python (2.7.13) the default.
But here
OK. I'll put it into my .profile and see what happens. Thanks.
The other issue I'm hitting is that the configure argument to enable wxPython,
'-with-wxwidgets=' expects a path to a wx_config file. AFAICT, wxPython 4 does
not have such a file. And I can't yet find anything that seems to serve the
On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton
wrote:
> I don't remember the exact wording. I had set up a conda virtual
> environment to force GRASS to compile and run with Anaconda Python and
> wxPython 4. When I launched GRASS (trunk), I got an error message that it
> would only run with a s
I just discovered something that has probably been giving increasing problems
lately. Because I've been building binaries, I have not looked at the grass.app
that is built from just running 'make install' in a long time.
It turns out that whatever creates the *.app automatically bundles some ver
I don't remember the exact wording. I had set up a conda virtual environment to
force GRASS to compile and run with Anaconda Python and wxPython 4. When I
launched GRASS (trunk), I got an error message that it would only run with a
system Python. I thought that is weird.
Anyway, I tried setting
On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton wrote:
> It seems that GRASS (at least GRASS for Mac) will only use the system
> Python. If I set up an environment in which Anaconda python is default,
> GRASS will not start and gives an error message that it will only run with
> the system Python.
It seems that GRASS (at least GRASS for Mac) will only use the system Python.
If I set up an environment in which Anaconda python is default, GRASS will not
start and gives an error message that it will only run with the system Python.
I don't know where this is coming from. It doesn't seem to b
On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton wrote:
>
>
> On Jul 27, 2017, at 12:46 PM, Anna Petrášová wrote:
>
> I think you can use pip to install it with whatever Python you use, at
> least that's what works on Linux.
>
>
> How do you specify which Python in pip?
It uses whichever Python i
On Jul 27, 2017, at 12:46 PM, Anna Petrášová
mailto:kratocha...@gmail.com>> wrote:
I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.
How do you specify which Python in pip?
Michael
C. Michael Barton
Director, Center
Anna,
Thanks for the quick response. See below.
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
On Thu, Jul 27, 2017 at 2:32 PM, Michael Barton wrote:
> Anna,
>
> Thanks for the quick response. See below.
>
> Michael
>
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Gra
Here is a report on this effort, including identifying several items that will
need to be changed by others for this to be successful.
I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
current OS (Sierra = OS X 10.12.x). I'm using the most current Kyngesburye
frameworks
On Thu, Jul 27, 2017 at 1:54 PM, Michael Barton wrote:
> Here is a report on this effort, including identifying several items that
> will need to be changed by others for this to be successful.
>
> I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
> current OS (Sierra = OS
On Thu, Jul 20, 2017 at 3:34 AM, Rainer Krug wrote:
> On 19 Jul 2017, at 21:54, Vaclav Petras wrote:
>
> On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton
> wrote:
>
>>
>> My group (CoMSES Net) is looking into Docker as a means of more
>> reproducible research in modeling science. Initial tests
On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton
wrote:
>
> My group (CoMSES Net) is looking into Docker as a means of more
> reproducible research in modeling science. Initial tests have gone OK, but
> show that doing software with a GUI is considerably more complicated than
> doing code that ju
Thanks Rainer,
If we can make GRASS install as much like a normal app as possible, it will be
accessible to more users. So that has been my goal. I will probably drop back
from the added things I was packaging previously (e.g., LAS support) to just
get a new system working if it can be done.
M
54 matches
Mail list logo