Re: [GRASS-user] grass-7.8.5 on Fedora 33
As a recent GRASS GIS-installation sufferer, I can explain what I did. Basically I followed Markus Neteler's instructions explicitly for installing 7.8.5. There were some small mistakes but he carefully corrected them. I used his instructions from the User Group regarding 7.8.5, and the instructions called for a two-step process (or three steps): download the 7.8.5 source tarball, use the script preparing for the compilation (which guarantees all the required software is installed), then run the compile, make, make install steps. Michael Allen Industrial Weather 763-777-1263 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, December 23, 2020 7:33 AM, Roger Bivand wrote: > I install from source, so cannot check. PROJ 7 needs Tiff and curl (to access > the CDN) over and above the sqlite3 requirement introduced by PROJ 6. Is the > install process pulling in PROJ > 6? I see 6.3.2 as the F33 current version, > but >= 7 would explain complaints about missing Tiff: > > $ pkg-config proj --libs --static > -L/usr/local/lib -lproj -lsqlite3 -ltiff -lcurl -lstdc++ > > > -- > > Roger Bivand > NHH Norwegian School of Economics, Bergen, Norway > > --- > > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html > > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Even I Don't Believe It: GRASS GIS worked!!
Well, sports fans, after another day of doing this and doing that, entering "grass78 --gui" suddenly displayed the well-illustrated gui!! I was certain it would crash, but there it is on one of the other monitors: in living color. I'll rehearse the details tomorrow since here in the Central time zone of North America it's now 11:30 pm. Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email.___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Umm...OK, How do I start this thing?
Thanks Rich. If this were a jigsaw puzzle I’d be missing the third piece. Michael Allen Industrial Weather 763-777-1263 On Mon, Dec 28, 2020 at 7:48 AM, Rich Shepard wrote: > On Mon, 28 Dec 2020, mdwxman wrote: > >> Very strange things happening here and I don't understand. > >> 1. I ran make install in the src directory and it finished without error. >> grass78 is in /usr/local/bin as it should be. But running grass78 from >> this directory produces this output: >> >> (base) [root@godelsrevenge ~]# /usr/local/bin/grass78 --gui >> Starting GRASS GIS... >> ERROR: wxGUI requires wxPython. No module named 'wx' >> >> I hope I've included enough detail to help with this. > > Michael, > > I faced this issue a few years ago. The solution is to add this line to > ~/.bash_profile: > > export GRASS_WXVERSION=4.1.0 > > or whichever version of wxPython is installed on that host. > > HTH, > > Rich > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Umm...OK, How do I start this thing?
Very strange things happening here and I don't understand.
1. I ran make install in the src directory and it finished without error.
grass78 is in /usr/local/bin as it should be. But running grass78 from this
directory produces this output:
(base) [root@godelsrevenge ~]# /usr/local/bin/grass78 --gui
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named 'wx'
You can still use GRASS GIS modules in the command line or in Python.
ERROR: Error in GUI startup. See messages above (if any) and if necessary,
please report this error to the GRASS developers.
On systems with package manager, make sure you have the right GUI package,
probably named grass-gui, installed.
To run GRASS GIS in text mode use the --text flag.
Use '--help' for further options
grass78 --help
See also: https://grass.osgeo.org/grass78/manuals/helptext.html
Exiting...
(base) [root@godelsrevenge ~]#
Checking for wxPython produces this:
(base) [root@godelsrevenge ~]# find / -name wxPython
find: File system loop detected; ‘/run/media/root/fedora_fedora5/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora4/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora3/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora2/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora1/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora/root’ is part
of the same file system loop as ‘/’.
/usr/lib64/python3.9/site-packages/wx/include/wxPython
The source file for grass-7.8.5 is at : /grass-7.8.5 NOT /root/grass-7.8.5.
Next I checked echo $PATH and received this message:
(base) [root@godelsrevenge ~]# echo $PATH
/usr/lib64/python3.9/site-packages/wx/include:/root/anaconda3/bin:/root/anaconda3/condabin:/usr/lib64/python3.9/site-packages/wx/include:/usr/lib64/ccache:/usr/local/sbin:/usr/sbin:/usr/local/bin:/usr/bin:/bin
(base) [root@godelsrevenge ~]#
but here's my .bashrc file:
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# User specific environment
# Uncomment the following line if you don't like systemctl's auto-paging
feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
# >>> Export for wxPython >>>
export PATH="/usr/lib64/python3.9/site-packages/wx/include:$PATH"
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/root/anaconda3/bin/conda' 'shell.bash' 'hook' 2>
/dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/root/anaconda3/etc/profile.d/conda.sh" ]; then
. "/root/anaconda3/etc/profile.d/conda.sh"
else
export PATH="/root/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<
So what is the origin of that long line of PATH directories when they don't
appear in the .bashrc file? (I checked to make sure I was running bash).
And if /usr/local/bin contains grass78 and wxPython is located in
/usr/lib64/python3.9/site-packages/wx/includes then why is grass78 missing the
wxPython file?
And I also checked using find / -name grass-gui and came up with nothing, that
is grass-gui is missing.
I hope I've included enough detail to help with this.
Michael Allen
Industrial Weather
763-777-1263
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, December 27, 2020 8:00 PM, Rich Shepard
wrote:
> On Sun, 27 Dec 2020, mdwxman wrote:
>
> > And that's a very good idea! I just went through the process of
creating a(base) [root@godelsrevenge ~]# find / -name wxPython
find: File system loop detected; ‘/run/media/root/fedora_fedora5/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora4/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora3/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora2/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora1/root’ is part
of the same file system loop as ‘/’.
find: File system loop detected; ‘/run/media/root/fedora_fedora/root’ is part
of the same file system loop as ‘/’.
/usr/lib64/python3.9/site-packages/wx/include/wxPython
(
> > link to the GRASS78 file. Your idea is something I never considered. I
> > guess too many years of managing Unix and Linux systems with command
lines
> > has stopped the creative juices from using the GUIs that were put
there
> > for everyone's benefit!
>
> Mike,
>
> Your method of invoking grass should reflect how you want to work with it.
Re: [GRASS-user] Umm...OK, How do I start this thing?
And that's a very good idea! I just went through the process of creating a link to the GRASS78 file. Your idea is something I never considered. I guess too many years of managing Unix and Linux systems with command lines has stopped the creative juices from using the GUIs that were put there for everyone's benefit! Mike Michael Allen Industrial Weather 763-777-1263 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, December 27, 2020 7:40 AM, Rich Shepard wrote: > On Sun, 27 Dec 2020, mdwxman via grass-user wrote: > > > I must be either blind or brain-frozen by all the snow outside but even > > after reading through the introductions and downloading the North Carolina > > data I still don't see how to start GRASS GIS 7.8.5 on my Fedora 33. I > > have over 30 years experience with Unix or Linux and I still don't see a > > startup file. What am I missing? > > Michael, > > You need to invoke the executable binary. On Slackware it's in > /usr/local/bin/. > > If you're using a virtual desktop (Gnome, KDE, Xfce4, whatever) you can > point an icon or menu item to that file and access it that way rather than > from a virtual terminal. > > Stay well, > > Rich > > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Umm...OK, How do I start this thing?
After all these years you would think that I would have automatically run “make install” or that I would have read the directions. Nope, not this time. Thanks for laying out the path comment. I’ll try to avoid being so neglectful in the future... Michael Allen Industrial Weather 763-777-1263 On Sun, Dec 27, 2020 at 1:38 AM, Markus Neteler wrote: > Hi Michael, > > mdwxman via grass-user schrieb am So., > 27. Dez. 2020, 06:19: >> >> I must be either blind or brain-frozen by all the snow outside but even >> after reading through the introductions >> and downloading the North Carolina data I still don't see how to start GRASS >> GIS 7.8.5 on my Fedora 33. > > The reason will be that the start script isn't yet in $PATH. > > So, the question is: did you run this step > > sudo make install > ? > > - if yes, then it should be in /usr/local/bin/ which needs to be in > $PATH (usually it is) > - if no, then you need to create a link: > ln -s /where/you/compiled/grass_src/bin.x86_64-pc-linux-gnu/grass78 > /some/directory/in/path/ > > Example (here in detail, also for others being interested): > So, in my $HOME I always create a "$HOME/bin/" directory into which I > then link the GRASS GIS startup script (and also other unrelated > stuff). Hence: > > mkdir $HOME/bin/ > > Then add this line into $HOME/.bashrc (assuming that you use bash shell): > export PATH=$PATH:$HOME/bin > > Next create the link (adapt path as needed): > ln -s $HOME/where/you/compiled/grass_src/bin.x86_64-pc-linux-gnu/grass78 > $HOME/bin/ > > Now either start a new terminal or execute one time (needed as the > current terminal only reads $HOME/.bashrc at startup): > export PATH=$PATH:$HOME/bin > > Now you should be able to start > > grass78 > >> I have over 30 years experience with Unix or Linux and I still don't see a >> startup file. What am I missing? > > It is all about having the start scipt in $PATH. > > HTH, > Markus___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Umm...OK, How do I start this thing?
I must be either blind or brain-frozen by all the snow outside but even after reading through the introductions and downloading the North Carolina data I still don't see how to start GRASS GIS 7.8.5 on my Fedora 33. I have over 30 years experience with Unix or Linux and I still don't see a startup file. What am I missing? Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email.___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] configure file for Fedora 33 and grass-7.8.5
It’s either perseverance or it’s a cumpulsive disorder of some type! This whole tale began last February when I realized a GIS would be perfect for displaying meteorological data. Software for numerical weather forecasting is rich in results but thin in display of topographic information. Reading through GRASS capabilities I realized it offered not just display but also analytical capacity. That was the inducement for continuing to find a solution for me. On the other hand, Markus’ willingness to smooth out the bumps, to pursue the complex interactions between libraries, and to volunteer so much time to someone like me is awe-inspiring. Linux is a very difficult platform due to its non-standard repos. Every one of Linux’s flavors is different. Add that to the welter of poorly-maintained libraries and very small but essential bits of code requires patience. He makes GRASS-GIS a workable solution. This users’ group is the key resource to making GRASS a very useful tool. My admiration and deep thanks. Michael Allen Industrial Weather 763-777-1263 On Wed, Dec 23, 2020 at 6:08 PM, Dave Roberts wrote: > Michael, you define perseverance. Markus, you are extraordinarily > gracious with your time and expertise. This is a happy outcome that > demonstrates the depth of commitment of the GRASS community. > > Bravo, Dave R. > > On 12/23/20 4:39 PM, mdwxman via grass-user wrote: >> GRASS GIS 7.8.5 exported compilation log >> -- >> Started compilation: Wed Dec 23 04:40:02 PM CST 2020 >> -- >> Errors in: >> No errors detected. >> -- >> Finished compilation: Wed Dec 23 04:40:40 PM CST 2020 >> >> SUCCESS!! There was another small hiccough (or is that now spelled >> differently? The cairo library also needed the devel files and a very >> small error during compilation as ~/raster3d/r3.in.asciialso needed to >> be compiled. Still, GRASS 7.8.5 is alive. >> >> Thank you Markus for all your patience and help. >> >> Michael Allen >> Industrial Weather >> 763-777-1263 >> >> Sent with ProtonMail >> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2F&data=04%7C01%7Cdroberts%40montana.edu%7C3b4ae4ea22964a595c4f08d8a79c0864%7C324aa97a03a644fc91e43846fbced113%7C0%7C0%7C637443636157311304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2AgtqY%2F4z6jG6LJP%2BXLIYflYKks5uko4vqPNr1CDcf4%3D&reserved=0> >> Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Wednesday, December 23, 2020 3:14 PM, mdwxman via grass-user >> wrote: >> >>> Yeah, I noticed that. Libtiff-devel now installed. >>> >>> Michael Allen >>> Industrial Weather >>> 763-777-1263 >>> >>> Sent with ProtonMail >>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.com%2F&data=04%7C01%7Cdroberts%40montana.edu%7C3b4ae4ea22964a595c4f08d8a79c0864%7C324aa97a03a644fc91e43846fbced113%7C0%7C0%7C637443636157321260%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jlgKyEhm534r1%2BPJ%2B04odu0XolgayGEt9xGrOOE8CMo%3D&reserved=0> >>> Secure Email. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Wednesday, December 23, 2020 2:08 PM, Markus Neteler >>> wrote: >>> >>>> Hi >>>> >>>> You need to install the development package as well which includes >>>> the header .h files: >>>> >>>> libtiff-devel >>>> >>>> Markus >>>> >>>> >>>> mdwxman via grass-user >>> <mailto:grass-user@lists.osgeo.org>> schrieb am Mi., 23. Dez. 2020, >>>> 20:39: >>>> >>>> And here's what I get from the dnf install libtiff: >>>> >>>> (base) [root@godelsrevenge ~]# dnf install libtiff >>>> Fedora Modular 33 - x86_64 - Updates >>>> 40 >>>> kB/s | 15 kB 00:00 >>>> Fedora 33 - x86_64 - Updates >>>> 54 >>>> kB/s | 16 kB 00:00 >>>> Package libtiff-4.1.0-4.fc33.x86_64 is already installed. >>>> Dependencies resolved. >>>> Nothing to do. >>>> Complete! >>>> >>>> Could it be that the Fedora 33 gremlins have inserted a >>>> differently-named libtiff version or a different location? >>>> >>>> Michael Allen >>>> Industrial Weather >>>> 763-777-1263 >>>> >>>> Sent with ProtonMail >>>> <https://nam10.safel
Re: [GRASS-user] configure file for Fedora 33 and grass-7.8.5
GRASS GIS 7.8.5 exported compilation log -- Started compilation: Wed Dec 23 04:40:02 PM CST 2020 -- Errors in: No errors detected. -- Finished compilation: Wed Dec 23 04:40:40 PM CST 2020 SUCCESS!! There was another small hiccough (or is that now spelled differently? The cairo library also needed the devel files and a very small error during compilation as ~/raster3d/r3.in.asciialso needed to be compiled. Still, GRASS 7.8.5 is alive. Thank you Markus for all your patience and help. Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, December 23, 2020 3:14 PM, mdwxman via grass-user wrote: > Yeah, I noticed that. Libtiff-devel now installed. > > Michael Allen > Industrial Weather > 763-777-1263 > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, December 23, 2020 2:08 PM, Markus Neteler > wrote: > >> Hi >> >> You need to install the development package as well which includes the >> header .h files: >> >> libtiff-devel >> >> Markus >> >> mdwxman via grass-user schrieb am Mi., 23. Dez. >> 2020, 20:39: >> >>> And here's what I get from the dnf install libtiff: >>> >>> (base) [root@godelsrevenge ~]# dnf install libtiff >>> Fedora Modular 33 - x86_64 - Updates 40 kB/s | 15 kB 00:00 >>> Fedora 33 - x86_64 - Updates 54 kB/s | 16 kB 00:00 >>> Package libtiff-4.1.0-4.fc33.x86_64 is already installed. >>> Dependencies resolved. >>> Nothing to do. >>> Complete! >>> >>> Could it be that the Fedora 33 gremlins have inserted a differently-named >>> libtiff version or a different location? >>> >>> Michael Allen >>> Industrial Weather >>> 763-777-1263 >>> >>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Wednesday, December 23, 2020 1:35 PM, mdwxman >>> wrote: >>> >>>> Evidently "TIFF" corresponds to libtiff. I'll attempt to dnf install. >>>> >>>> Michael Allen >>>> Industrial Weather >>>> 763-777-1263 >>>> >>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Wednesday, December 23, 2020 1:32 PM, mdwxman via grass-user >>>> wrote: >>>> >>>>> Markus: >>>>> >>>>> Who knows what the configure means by "TIFF missing?" But here's the >>>>> configure file and the result: >>>>> (base) [root@godelsrevenge grass-7.8.5]# ./configure \ >>>>>> --with-cxx \ >>>>>> --with-gdal=/usr/bin/gdal-config \ >>>>>> --with-proj --with-proj-share=/usr/share/proj \ >>>>>> --with-geos \ >>>>>> --with-sqlite \ >>>>>> --with-nls \ >>>>>> --with-wxwidgets=/usr/bin/wx-config \ >>>>>> --with-fftw \ >>>>>> --with-cairo --with-cairo-ldflags=-ldfontconfig \ >>>>>> --with-freetype --with-freetype-includes=/usr/include/freetype2 \ >>>>>> --enable-largefile \ >>>>>> --without-odbc \ >>>>>> --with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \ >>>>>> --with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \ >>>>>> --with-zstd >>>>> checking host system type... x86_64-pc-linux-gnu >>>>> checking for gcc... gcc >>>>> checking whether the C compiler (gcc ) works... yes >>>>> checking whether the C compiler (gcc ) is a cross-compiler... no >>>>> checking whether we are using GNU C... yes >>>>> checking whether gcc accepts -g... yes >>>>> checking for Cygwin environment... no >>>>> checking for mingw32 environment... no >>>>> checking for executable suffix... no >>>>> checking for full floating-point support... yes >>>>> checking for pwd... /usr/bin/pwd >>>>> checking for source directory... /grass-7.8.5 >>>>> checking for build directory... /grass-7.8.5 >>>>> checking for git... /usr/bin/git >>>>> fatal: not a git repository (or any of the parent directories): .git >>>>> checking for MacOSX App... no >>>>>
Re: [GRASS-user] configure file for Fedora 33 and grass-7.8.5
Yeah, I noticed that. Libtiff-devel now installed. Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, December 23, 2020 2:08 PM, Markus Neteler wrote: > Hi > > You need to install the development package as well which includes the header > .h files: > > libtiff-devel > > Markus > > mdwxman via grass-user schrieb am Mi., 23. Dez. > 2020, 20:39: > >> And here's what I get from the dnf install libtiff: >> >> (base) [root@godelsrevenge ~]# dnf install libtiff >> Fedora Modular 33 - x86_64 - Updates 40 kB/s | 15 kB 00:00 >> Fedora 33 - x86_64 - Updates 54 kB/s | 16 kB 00:00 >> Package libtiff-4.1.0-4.fc33.x86_64 is already installed. >> Dependencies resolved. >> Nothing to do. >> Complete! >> >> Could it be that the Fedora 33 gremlins have inserted a differently-named >> libtiff version or a different location? >> >> Michael Allen >> Industrial Weather >> 763-777-1263 >> >> Sent with [ProtonMail](https://protonmail.com) Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Wednesday, December 23, 2020 1:35 PM, mdwxman >> wrote: >> >>> Evidently "TIFF" corresponds to libtiff. I'll attempt to dnf install. >>> >>> Michael Allen >>> Industrial Weather >>> 763-777-1263 >>> >>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Wednesday, December 23, 2020 1:32 PM, mdwxman via grass-user >>> wrote: >>> >>>> Markus: >>>> >>>> Who knows what the configure means by "TIFF missing?" But here's the >>>> configure file and the result: >>>> (base) [root@godelsrevenge grass-7.8.5]# ./configure \ >>>>> --with-cxx \ >>>>> --with-gdal=/usr/bin/gdal-config \ >>>>> --with-proj --with-proj-share=/usr/share/proj \ >>>>> --with-geos \ >>>>> --with-sqlite \ >>>>> --with-nls \ >>>>> --with-wxwidgets=/usr/bin/wx-config \ >>>>> --with-fftw \ >>>>> --with-cairo --with-cairo-ldflags=-ldfontconfig \ >>>>> --with-freetype --with-freetype-includes=/usr/include/freetype2 \ >>>>> --enable-largefile \ >>>>> --without-odbc \ >>>>> --with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \ >>>>> --with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \ >>>>> --with-zstd >>>> checking host system type... x86_64-pc-linux-gnu >>>> checking for gcc... gcc >>>> checking whether the C compiler (gcc ) works... yes >>>> checking whether the C compiler (gcc ) is a cross-compiler... no >>>> checking whether we are using GNU C... yes >>>> checking whether gcc accepts -g... yes >>>> checking for Cygwin environment... no >>>> checking for mingw32 environment... no >>>> checking for executable suffix... no >>>> checking for full floating-point support... yes >>>> checking for pwd... /usr/bin/pwd >>>> checking for source directory... /grass-7.8.5 >>>> checking for build directory... /grass-7.8.5 >>>> checking for git... /usr/bin/git >>>> fatal: not a git repository (or any of the parent directories): .git >>>> checking for MacOSX App... no >>>> checking for MacOSX architectures... no >>>> checking for MacOSX SDK... no >>>> checking how to build libraries... shared >>>> checking for additional include dirs... >>>> checking for additional library dirs... >>>> checking for a BSD compatible install... /usr/bin/install -c >>>> checking for flex... flex >>>> checking for yywrap in -lfl... no >>>> checking for bison... bison -y >>>> checking for ranlib... ranlib >>>> checking for ar... ar >>>> checking for env... env >>>> checking for perl... /usr/bin/perl >>>> checking how to run the C preprocessor... gcc -E >>>> checking for ANSI C header files... yes >>>> checking for limits.h... yes >>>> checking for termio.h... yes >>>> checking for termios.h... yes >>>> checking for unistd.h... yes >>>> checking for values.h... yes >>>> checking for f2c.h... no >>>> checking for g2c.h... no >>>> checking for sys/ioctl.h... yes
Re: [GRASS-user] configure file for Fedora 33 and grass-7.8.5
And here's what I get from the dnf install libtiff: (base) [root@godelsrevenge ~]# dnf install libtiff Fedora Modular 33 - x86_64 - Updates 40 kB/s | 15 kB 00:00 Fedora 33 - x86_64 - Updates 54 kB/s | 16 kB 00:00 Package libtiff-4.1.0-4.fc33.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! Could it be that the Fedora 33 gremlins have inserted a differently-named libtiff version or a different location? Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, December 23, 2020 1:35 PM, mdwxman wrote: > Evidently "TIFF" corresponds to libtiff. I'll attempt to dnf install. > > Michael Allen > Industrial Weather > 763-777-1263 > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, December 23, 2020 1:32 PM, mdwxman via grass-user > wrote: > >> Markus: >> >> Who knows what the configure means by "TIFF missing?" But here's the >> configure file and the result: >> (base) [root@godelsrevenge grass-7.8.5]# ./configure \ >>> --with-cxx \ >>> --with-gdal=/usr/bin/gdal-config \ >>> --with-proj --with-proj-share=/usr/share/proj \ >>> --with-geos \ >>> --with-sqlite \ >>> --with-nls \ >>> --with-wxwidgets=/usr/bin/wx-config \ >>> --with-fftw \ >>> --with-cairo --with-cairo-ldflags=-ldfontconfig \ >>> --with-freetype --with-freetype-includes=/usr/include/freetype2 \ >>> --enable-largefile \ >>> --without-odbc \ >>> --with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \ >>> --with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \ >>> --with-zstd >> checking host system type... x86_64-pc-linux-gnu >> checking for gcc... gcc >> checking whether the C compiler (gcc ) works... yes >> checking whether the C compiler (gcc ) is a cross-compiler... no >> checking whether we are using GNU C... yes >> checking whether gcc accepts -g... yes >> checking for Cygwin environment... no >> checking for mingw32 environment... no >> checking for executable suffix... no >> checking for full floating-point support... yes >> checking for pwd... /usr/bin/pwd >> checking for source directory... /grass-7.8.5 >> checking for build directory... /grass-7.8.5 >> checking for git... /usr/bin/git >> fatal: not a git repository (or any of the parent directories): .git >> checking for MacOSX App... no >> checking for MacOSX architectures... no >> checking for MacOSX SDK... no >> checking how to build libraries... shared >> checking for additional include dirs... >> checking for additional library dirs... >> checking for a BSD compatible install... /usr/bin/install -c >> checking for flex... flex >> checking for yywrap in -lfl... no >> checking for bison... bison -y >> checking for ranlib... ranlib >> checking for ar... ar >> checking for env... env >> checking for perl... /usr/bin/perl >> checking how to run the C preprocessor... gcc -E >> checking for ANSI C header files... yes >> checking for limits.h... yes >> checking for termio.h... yes >> checking for termios.h... yes >> checking for unistd.h... yes >> checking for values.h... yes >> checking for f2c.h... no >> checking for g2c.h... no >> checking for sys/ioctl.h... yes >> checking for sys/mtio.h... yes >> checking for sys/resource.h... yes >> checking for sys/time.h... yes >> checking for sys/timeb.h... yes >> checking for sys/types.h... yes >> checking for sys/utsname.h... yes >> checking for libintl.h... yes >> checking for iconv.h... yes >> checking for langinfo.h... yes >> checking whether time.h and sys/time.h may both be included... yes >> checking for off_t... yes >> checking for uid_t in sys/types.h... yes >> checking return type of signal handlers... void >> checking for Cygwin environment... no >> checking for ftime... yes >> checking for gethostname... yes >> checking for gettimeofday... yes >> checking for lseek... yes >> checking for nice... yes >> checking for time... yes >> checking for uname... yes >> checking for seteuid... yes >> checking for setpriority... yes >> checking for setreuid... yes >> checking for setruid... no >> checking for drand48... yes >> checking for putenv... yes >> checking for setenv... yes >> checking for nanosleep... yes >> checking whether setpgrp takes no argument... yes >> checking for l
Re: [GRASS-user] configure file for Fedora 33 and grass-7.8.5
Evidently "TIFF" corresponds to libtiff. I'll attempt to dnf install. Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, December 23, 2020 1:32 PM, mdwxman via grass-user wrote: > Markus: > > Who knows what the configure means by "TIFF missing?" But here's the > configure file and the result: > (base) [root@godelsrevenge grass-7.8.5]# ./configure \ >> --with-cxx \ >> --with-gdal=/usr/bin/gdal-config \ >> --with-proj --with-proj-share=/usr/share/proj \ >> --with-geos \ >> --with-sqlite \ >> --with-nls \ >> --with-wxwidgets=/usr/bin/wx-config \ >> --with-fftw \ >> --with-cairo --with-cairo-ldflags=-ldfontconfig \ >> --with-freetype --with-freetype-includes=/usr/include/freetype2 \ >> --enable-largefile \ >> --without-odbc \ >> --with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \ >> --with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \ >> --with-zstd > checking host system type... x86_64-pc-linux-gnu > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for Cygwin environment... no > checking for mingw32 environment... no > checking for executable suffix... no > checking for full floating-point support... yes > checking for pwd... /usr/bin/pwd > checking for source directory... /grass-7.8.5 > checking for build directory... /grass-7.8.5 > checking for git... /usr/bin/git > fatal: not a git repository (or any of the parent directories): .git > checking for MacOSX App... no > checking for MacOSX architectures... no > checking for MacOSX SDK... no > checking how to build libraries... shared > checking for additional include dirs... > checking for additional library dirs... > checking for a BSD compatible install... /usr/bin/install -c > checking for flex... flex > checking for yywrap in -lfl... no > checking for bison... bison -y > checking for ranlib... ranlib > checking for ar... ar > checking for env... env > checking for perl... /usr/bin/perl > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for limits.h... yes > checking for termio.h... yes > checking for termios.h... yes > checking for unistd.h... yes > checking for values.h... yes > checking for f2c.h... no > checking for g2c.h... no > checking for sys/ioctl.h... yes > checking for sys/mtio.h... yes > checking for sys/resource.h... yes > checking for sys/time.h... yes > checking for sys/timeb.h... yes > checking for sys/types.h... yes > checking for sys/utsname.h... yes > checking for libintl.h... yes > checking for iconv.h... yes > checking for langinfo.h... yes > checking whether time.h and sys/time.h may both be included... yes > checking for off_t... yes > checking for uid_t in sys/types.h... yes > checking return type of signal handlers... void > checking for Cygwin environment... no > checking for ftime... yes > checking for gethostname... yes > checking for gettimeofday... yes > checking for lseek... yes > checking for nice... yes > checking for time... yes > checking for uname... yes > checking for seteuid... yes > checking for setpriority... yes > checking for setreuid... yes > checking for setruid... no > checking for drand48... yes > checking for putenv... yes > checking for setenv... yes > checking for nanosleep... yes > checking whether setpgrp takes no argument... yes > checking for long long int... yes > checking for int64_t... yes > checking for W11... no > checking for X... libraries , headers > checking for dnet_ntoa in -ldnet... no > checking for dnet_ntoa in -ldnet_stub... no > checking for gethostbyname... yes > checking for connect... yes > checking for remove... yes > checking for shmat... yes > checking for IceConnectionNumber in -lICE... yes > checking for library containing cuserid... none required > checking for asprintf... yes > checking for atan... no > checking for atan in -lm... yes > checking for dlsym... no > checking for dlsym in -ldl... yes > checking for iconv... yes > checking for socket... yes > checking for location of zlib includes... > checking for zlib.h... yes > checking for location of zlib library... > checking for deflate in -lz... yes > checking whether to use bzlib... no > checking whether to use zstd... yes > checking for location of zstd includes... > checking for zstd.h... yes > checking for location of zstd
[GRASS-user] configure file for Fedora 33 and grass-7.8.5
Markus: Who knows what the configure means by "TIFF missing?" But here's the configure file and the result: (base) [root@godelsrevenge grass-7.8.5]# ./configure \ > --with-cxx \ > --with-gdal=/usr/bin/gdal-config \ > --with-proj --with-proj-share=/usr/share/proj \ > --with-geos \ > --with-sqlite \ > --with-nls \ > --with-wxwidgets=/usr/bin/wx-config \ > --with-fftw \ > --with-cairo --with-cairo-ldflags=-ldfontconfig \ > --with-freetype --with-freetype-includes=/usr/include/freetype2 \ > --enable-largefile \ > --without-odbc \ > --with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \ > --with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \ > --with-zstd checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no checking for full floating-point support... yes checking for pwd... /usr/bin/pwd checking for source directory... /grass-7.8.5 checking for build directory... /grass-7.8.5 checking for git... /usr/bin/git fatal: not a git repository (or any of the parent directories): .git checking for MacOSX App... no checking for MacOSX architectures... no checking for MacOSX SDK... no checking how to build libraries... shared checking for additional include dirs... checking for additional library dirs... checking for a BSD compatible install... /usr/bin/install -c checking for flex... flex checking for yywrap in -lfl... no checking for bison... bison -y checking for ranlib... ranlib checking for ar... ar checking for env... env checking for perl... /usr/bin/perl checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for limits.h... yes checking for termio.h... yes checking for termios.h... yes checking for unistd.h... yes checking for values.h... yes checking for f2c.h... no checking for g2c.h... no checking for sys/ioctl.h... yes checking for sys/mtio.h... yes checking for sys/resource.h... yes checking for sys/time.h... yes checking for sys/timeb.h... yes checking for sys/types.h... yes checking for sys/utsname.h... yes checking for libintl.h... yes checking for iconv.h... yes checking for langinfo.h... yes checking whether time.h and sys/time.h may both be included... yes checking for off_t... yes checking for uid_t in sys/types.h... yes checking return type of signal handlers... void checking for Cygwin environment... no checking for ftime... yes checking for gethostname... yes checking for gettimeofday... yes checking for lseek... yes checking for nice... yes checking for time... yes checking for uname... yes checking for seteuid... yes checking for setpriority... yes checking for setreuid... yes checking for setruid... no checking for drand48... yes checking for putenv... yes checking for setenv... yes checking for nanosleep... yes checking whether setpgrp takes no argument... yes checking for long long int... yes checking for int64_t... yes checking for W11... no checking for X... libraries , headers checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for library containing cuserid... none required checking for asprintf... yes checking for atan... no checking for atan in -lm... yes checking for dlsym... no checking for dlsym in -ldl... yes checking for iconv... yes checking for socket... yes checking for location of zlib includes... checking for zlib.h... yes checking for location of zlib library... checking for deflate in -lz... yes checking whether to use bzlib... no checking whether to use zstd... yes checking for location of zstd includes... checking for zstd.h... yes checking for location of zstd library... checking for ZSTD_compress in -lzstd... yes checking for location of External PROJ includes... checking for proj.h... yes checking External PROJ major version... 6 checking External PROJ minor version... 3 checking External PROJ patch version... 2 found PROJ version 6.3.2 using new PROJ version 5+ API checking for location of External PROJ library... checking for proj_pj_info in -lproj... yes checking for location of External PROJ data files... /usr/share/proj checking whether to use regex... yes checking for location of regex includes... checking for regex.h... yes checking for location of regex library... checking for regcomp... yes checking whether to use Readline... no checking whether to use GDAL... yes checking for gdal-config... /usr/bin/gdal-config checking whether to use libLAS... no checking whether to use PDAL... no checking whether to use NetCDF... no checking whether to use GEOS... yes checking
[GRASS-user] grass-7.8.5 on Fedora 33
So, far, I must be cursed... I successfully loaded and configured Fedora 33 with the KDE desktop (much better than GNOME 3; used it long ago). Downloaded grass-7.8.5 from the tarball, etc. Read and followed directions on https://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_GIS_7_on_Fedora Nearly everything downloaded and installed from the dnf install file except for the proj-epsg item. Nevertheless, I went ahead with the ./configure script then was shot down by the "couldn't find the TIFF" item. Evidently dnf install can't find it and Fedora 33 doesn't have it on my machine. (I used the "Everything" option, although I chose only some of the items). I attempted to use dnf to find TIFF but it failed. If TIFF is related to the protocol for displaying *.tiff images then I'm confused. Or if there are some other instructions for grass-7.8.5 on Fedora I haven't found them yet. Any suggestions? Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email.___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
Simply by looking at Fedora’s Web site I can see many more choices than I ever saw with CentOS. Any recommendations regarding which of Fedora’s installations might be best? Michael Allen Industrial Weather 763-777-1263 On Sat, Dec 19, 2020 at 11:08 AM, mdwxman via grass-user wrote: > The Fedora choice is undoubtedly a better choice in my case since it’s more > familiar. It has usually been much more up-to-date too. > > Thanks for the advice. > > Michael Allen > Industrial Weather > 763-777-1263 > > On Sat, Dec 19, 2020 at 11:00 AM, Markus Neteler wrote: > >> On Sat, Dec 19, 2020 at 5:50 PM mdwxman wrote: >>> >>> OK. It would be much easier to move to Fedora since CentOS is similar to >>> Fedora. I used Fedora years ago and changed to CentOS at about CentOS 5. >>> Too much time wasted to continue with CentOS. >> >> You'll find the geo stuff up to date in Fedora, and you will be >> familiar with the package management system. >> >> Markus___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
The Fedora choice is undoubtedly a better choice in my case since it’s more familiar. It has usually been much more up-to-date too. Thanks for the advice. Michael Allen Industrial Weather 763-777-1263 On Sat, Dec 19, 2020 at 11:00 AM, Markus Neteler wrote: > On Sat, Dec 19, 2020 at 5:50 PM mdwxman wrote: >> >> OK. It would be much easier to move to Fedora since CentOS is similar to >> Fedora. I used Fedora years ago and changed to CentOS at about CentOS 5. Too >> much time wasted to continue with CentOS. > > You'll find the geo stuff up to date in Fedora, and you will be > familiar with the package management system. > > Markus___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
I’ve even found the DHCP/static issue to be impossible. I have 5 static lines here but as of last week (and actually several months ago) I’ve been unable to configure static addresses on the CentOS 8 machine. CentOS 8 requires NetworkManager and that reverts to DHCP no matter which NIC configuration I use. Dry sloppy work on their part. Michael Allen Industrial Weather 763-777-1263 On Sat, Dec 19, 2020 at 10:59 AM, Micha Silver wrote: > On 12/19/20 6:38 PM, mdwxman via grass-user wrote: > >> I’m starting to agree with you regarding Centos 8. This experience matches >> other experiences with it. Although I like it’s interface there seems to be >> serious, nefarious hidden issues when I start to compile code. I understand >> why it ‘s been abandoned, although I have no research to add to my >> suppositions. >> >> If old habits die hard those old habits can still have disastrous >> consequences. Today is the day to adopt Ubuntu & stop wasting my time & >> yours. I wonder how many others on this user group use CentOS 7 or 8? Not >> many I’d guess. > > Like you I also used CentOS for years, but left several years back for the > Debian family. I've been quite happy since. > > CentOS is still a good choice, I think, if you need a server for just a few > standard, unchanging services (DHCP, web server, mail server etc). But for > desktop work, with rapidly changing software, you quickly find yourself > chasing after packages that aren't available from the standard repos. > >> Michael Allen >> Industrial Weather >> 763-777-1263 >> >> On Sat, Dec 19, 2020 at 5:53 AM, Markus Neteler wrote: >> >>> On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user >>> [](mailto:grass-user@lists.osgeo.org) wrote: >>>> >>>> This has become a very strange issue. This afternoon I attempted 8 >>>> variations on the compilation and all failed. >>> >>> There should ideally be just one way to install it. >>> >>>> The first thing I did was to check on the GDAL version and although it >>>> wasn't easy, it turns out that the conda installation from several weeks >>>> ago used GDAL 2.4... The GRASS version was the 7.7 version. So, I changed >>>> the subdirectory to the 3.0.4 GDAL version: /usr/include/gdal-config and >>>> the /usr/share/gdal subdirectories. But those failed too although I used >>>> the grass-7.8.5RC1 file. >>> >>> We need to see the error messages to help. >>> >>> In the first place I feel that you have a mixture of version on your >>> machine. Personally, I would try without conda on Centos8. >>> >>>> I also checked my logs and made sure I used the dnf install text for all >>>> the required software. I also tried the "--with-gdal >>>> --with-gdal-includes=/usr/include/gdal" configuration. All my attempts >>>> bombed. >>>> >>>> It was interesting that dnf install noted that GDAL and GDAL-devel were >>>> the most recent and already on my file system. There are two additional >>>> tasks to do now. The first is to discover whether the GDAL and GDAL-devel >>>> version 3.0.4 version is the one to use for the compilation. Is it the >>>> most up-to-date? >>> >>> Here you can look up the version: >>> https://src.fedoraproject.org/rpms/gdal/ >>> --> d'oh! where did it go? Someone must have removed it from there ... :( >>> >>> ==> Build status >>> --> https://koji.fedoraproject.org/koji/packageinfo?packageID=1826 >>> --> gdal-3.0.4-5.el8 (which I packaged in May) >>> >>> I have just triggered to rebuild it on the server: >>> >>> fedpkg build >>> Building gdal-3.0.4-6.el8 for epel8-candidate >>> Created task: 57788230 >>> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788230 >>> Building gdal-3.0.4-6.el8 for epel8-playground-candidate >>> Created task: 57788232 >>> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788232 >>> >>> ==> it fails. >>> >>>> The other task is attempt to dig into other log files to determine if >>>> there is additional information. >>>> >>>> After that I plan to remove all GRASS versions and related libraries if I >>>> can find them. I know I have two GRASS versions: 7.7 and 7.8.5 so perhaps >>>> there's a conflict hidden in the configuration. >>> >>> Is there any
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
OK. It would be much easier to move to Fedora since CentOS is similar to Fedora. I used Fedora years ago and changed to CentOS at about CentOS 5. Too much time wasted to continue with CentOS. Michael Allen Industrial Weather 763-777-1263 On Sat, Dec 19, 2020 at 5:53 AM, Markus Neteler wrote: > On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user > wrote: >> >> This has become a very strange issue. This afternoon I attempted 8 >> variations on the compilation and all failed. > > There should ideally be just one way to install it. > >> The first thing I did was to check on the GDAL version and although it >> wasn't easy, it turns out that the conda installation from several weeks ago >> used GDAL 2.4... The GRASS version was the 7.7 version. So, I changed the >> subdirectory to the 3.0.4 GDAL version: /usr/include/gdal-config and the >> /usr/share/gdal subdirectories. But those failed too although I used the >> grass-7.8.5RC1 file. > > We need to see the error messages to help. > > In the first place I feel that you have a mixture of version on your > machine. Personally, I would try without conda on Centos8. > >> I also checked my logs and made sure I used the dnf install text for all the >> required software. I also tried the "--with-gdal >> --with-gdal-includes=/usr/include/gdal" configuration. All my attempts >> bombed. >> >> It was interesting that dnf install noted that GDAL and GDAL-devel were the >> most recent and already on my file system. There are two additional tasks to >> do now. The first is to discover whether the GDAL and GDAL-devel version >> 3.0.4 version is the one to use for the compilation. Is it the most >> up-to-date? > > Here you can look up the version: > https://src.fedoraproject.org/rpms/gdal/ > --> d'oh! where did it go? Someone must have removed it from there ... :( > > ==> Build status > --> https://koji.fedoraproject.org/koji/packageinfo?packageID=1826 > --> gdal-3.0.4-5.el8 (which I packaged in May) > > I have just triggered to rebuild it on the server: > > fedpkg build > Building gdal-3.0.4-6.el8 for epel8-candidate > Created task: 57788230 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788230 > Building gdal-3.0.4-6.el8 for epel8-playground-candidate > Created task: 57788232 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788232 > > ==> it fails. > >> The other task is attempt to dig into other log files to determine if there >> is additional information. >> >> After that I plan to remove all GRASS versions and related libraries if I >> can find them. I know I have two GRASS versions: 7.7 and 7.8.5 so perhaps >> there's a conflict hidden in the configuration. > > Is there any reason to keep the outdated GRASS 7.7? > >> My other question revolves around gdal-config. There are two versions of >> gdal-config: one simply called "gdal-config" and the other called >> "gdal-config64" This machine (and all my networked machines) are x86_64 >> architecture. Is the configure script attempting to use one or the other and >> defaulting to the "Error: cannot find gdal-config" option. This type of >> thing has happened to me before and error messages can be notoriously >> difficult to understand. > > I fully agree. There is no (obvious) point for me to have a separate > "gdal-config64" script. > Please check from which RPM it originates, with > > rpm -qf /usr/bin/gdal-config64 > ? > > But honestly, I am getting lost with Centos. That's why we abandoned > it earlier this year (which was an attempt after 10 years of > Scientific Linux on our HPC infrastructure). > > However, I have good experience with Fedora and Ubuntu. > > Markus___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
BTW, there is no reason to keep the outdated vs. 7.7. Since I’m going to wipe the 8 Tb from that machine and move to Ubuntu on all the others, that will disappear as well. Michael Allen Industrial Weather 763-777-1263 On Sat, Dec 19, 2020 at 5:53 AM, Markus Neteler wrote: > On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user > wrote: >> >> This has become a very strange issue. This afternoon I attempted 8 >> variations on the compilation and all failed. > > There should ideally be just one way to install it. > >> The first thing I did was to check on the GDAL version and although it >> wasn't easy, it turns out that the conda installation from several weeks ago >> used GDAL 2.4... The GRASS version was the 7.7 version. So, I changed the >> subdirectory to the 3.0.4 GDAL version: /usr/include/gdal-config and the >> /usr/share/gdal subdirectories. But those failed too although I used the >> grass-7.8.5RC1 file. > > We need to see the error messages to help. > > In the first place I feel that you have a mixture of version on your > machine. Personally, I would try without conda on Centos8. > >> I also checked my logs and made sure I used the dnf install text for all the >> required software. I also tried the "--with-gdal >> --with-gdal-includes=/usr/include/gdal" configuration. All my attempts >> bombed. >> >> It was interesting that dnf install noted that GDAL and GDAL-devel were the >> most recent and already on my file system. There are two additional tasks to >> do now. The first is to discover whether the GDAL and GDAL-devel version >> 3.0.4 version is the one to use for the compilation. Is it the most >> up-to-date? > > Here you can look up the version: > https://src.fedoraproject.org/rpms/gdal/ > --> d'oh! where did it go? Someone must have removed it from there ... :( > > ==> Build status > --> https://koji.fedoraproject.org/koji/packageinfo?packageID=1826 > --> gdal-3.0.4-5.el8 (which I packaged in May) > > I have just triggered to rebuild it on the server: > > fedpkg build > Building gdal-3.0.4-6.el8 for epel8-candidate > Created task: 57788230 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788230 > Building gdal-3.0.4-6.el8 for epel8-playground-candidate > Created task: 57788232 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788232 > > ==> it fails. > >> The other task is attempt to dig into other log files to determine if there >> is additional information. >> >> After that I plan to remove all GRASS versions and related libraries if I >> can find them. I know I have two GRASS versions: 7.7 and 7.8.5 so perhaps >> there's a conflict hidden in the configuration. > > Is there any reason to keep the outdated GRASS 7.7? > >> My other question revolves around gdal-config. There are two versions of >> gdal-config: one simply called "gdal-config" and the other called >> "gdal-config64" This machine (and all my networked machines) are x86_64 >> architecture. Is the configure script attempting to use one or the other and >> defaulting to the "Error: cannot find gdal-config" option. This type of >> thing has happened to me before and error messages can be notoriously >> difficult to understand. > > I fully agree. There is no (obvious) point for me to have a separate > "gdal-config64" script. > Please check from which RPM it originates, with > > rpm -qf /usr/bin/gdal-config64 > ? > > But honestly, I am getting lost with Centos. That's why we abandoned > it earlier this year (which was an attempt after 10 years of > Scientific Linux on our HPC infrastructure). > > However, I have good experience with Fedora and Ubuntu. > > Markus___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
I’m starting to agree with you regarding Centos 8. This experience matches other experiences with it. Although I like it’s interface there seems to be serious, nefarious hidden issues when I start to compile code. I understand why it ‘s been abandoned, although I have no research to add to my suppositions. If old habits die hard those old habits can still have disastrous consequences. Today is the day to adopt Ubuntu & stop wasting my time & yours. I wonder how many others on this user group use CentOS 7 or 8? Not many I’d guess. Michael Allen Industrial Weather 763-777-1263 On Sat, Dec 19, 2020 at 5:53 AM, Markus Neteler wrote: > On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user > wrote: >> >> This has become a very strange issue. This afternoon I attempted 8 >> variations on the compilation and all failed. > > There should ideally be just one way to install it. > >> The first thing I did was to check on the GDAL version and although it >> wasn't easy, it turns out that the conda installation from several weeks ago >> used GDAL 2.4... The GRASS version was the 7.7 version. So, I changed the >> subdirectory to the 3.0.4 GDAL version: /usr/include/gdal-config and the >> /usr/share/gdal subdirectories. But those failed too although I used the >> grass-7.8.5RC1 file. > > We need to see the error messages to help. > > In the first place I feel that you have a mixture of version on your > machine. Personally, I would try without conda on Centos8. > >> I also checked my logs and made sure I used the dnf install text for all the >> required software. I also tried the "--with-gdal >> --with-gdal-includes=/usr/include/gdal" configuration. All my attempts >> bombed. >> >> It was interesting that dnf install noted that GDAL and GDAL-devel were the >> most recent and already on my file system. There are two additional tasks to >> do now. The first is to discover whether the GDAL and GDAL-devel version >> 3.0.4 version is the one to use for the compilation. Is it the most >> up-to-date? > > Here you can look up the version: > https://src.fedoraproject.org/rpms/gdal/ > --> d'oh! where did it go? Someone must have removed it from there ... :( > > ==> Build status > --> https://koji.fedoraproject.org/koji/packageinfo?packageID=1826 > --> gdal-3.0.4-5.el8 (which I packaged in May) > > I have just triggered to rebuild it on the server: > > fedpkg build > Building gdal-3.0.4-6.el8 for epel8-candidate > Created task: 57788230 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788230 > Building gdal-3.0.4-6.el8 for epel8-playground-candidate > Created task: 57788232 > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788232 > > ==> it fails. > >> The other task is attempt to dig into other log files to determine if there >> is additional information. >> >> After that I plan to remove all GRASS versions and related libraries if I >> can find them. I know I have two GRASS versions: 7.7 and 7.8.5 so perhaps >> there's a conflict hidden in the configuration. > > Is there any reason to keep the outdated GRASS 7.7? > >> My other question revolves around gdal-config. There are two versions of >> gdal-config: one simply called "gdal-config" and the other called >> "gdal-config64" This machine (and all my networked machines) are x86_64 >> architecture. Is the configure script attempting to use one or the other and >> defaulting to the "Error: cannot find gdal-config" option. This type of >> thing has happened to me before and error messages can be notoriously >> difficult to understand. > > I fully agree. There is no (obvious) point for me to have a separate > "gdal-config64" script. > Please check from which RPM it originates, with > > rpm -qf /usr/bin/gdal-config64 > ? > > But honestly, I am getting lost with Centos. That's why we abandoned > it earlier this year (which was an attempt after 10 years of > Scientific Linux on our HPC infrastructure). > > However, I have good experience with Fedora and Ubuntu. > > Markus___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
This has become a very strange issue. This afternoon I attempted 8 variations on the compilation and all failed. The first thing I did was to check on the GDAL version and although it wasn't easy, it turns out that the conda installation from several weeks ago used GDAL 2.4... The GRASS version was the 7.7 version. So, I changed the subdirectory to the 3.0.4 GDAL version: /usr/include/gdal-config and the /usr/share/gdal subdirectories. But those failed too although I used the grass-7.8.5RC1 file. I also checked my logs and made sure I used the dnf install text for all the required software. I also tried the "--with-gdal --with-gdal-includes=/usr/include/gdal" configuration. All my attempts bombed. It was interesting that dnf install noted that GDAL and GDAL-devel were the most recent and already on my file system. There are two additional tasks to do now. The first is to discover whether the GDAL and GDAL-devel version 3.0.4 version is the one to use for the compilation. Is it the most up-to-date? The other task is attempt to dig into other log files to determine if there is additional information. After that I plan to remove all GRASS versions and related libraries if I can find them. I know I have two GRASS versions: 7.7 and 7.8.5 so perhaps there's a conflict hidden in the configuration. My other question revolves around gdal-config. There are two versions of gdal-config: one simply called "gdal-config" and the other called "gdal-config64" This machine (and all my networked machines) are x86_64 architecture. Is the configure script attempting to use one or the other and defaulting to the "Error: cannot find gdal-config" option. This type of thing has happened to me before and error messages can be notoriously difficult to understand. Any other suggestions would be gladly entertained or even grasped or even prayed for!! Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, December 17, 2020 10:19 PM, mdwxman via grass-user wrote: > Looks like more fun here at dog fur manor. I'm still stuck on the compilation > of grass-7.8.5RC1 on CentOS 8. > > The script stops at line 6788 in the configure script with the ERROR message: > Cannot find grass-config. > > I've moved grass-config to many different subdirectories but always with the > same result. I used the methods on > https://grasswiki.osgeo.org/wiki/Compile_and_Install#CentOS under the CentOS > 8 and the GRASS 7 instructions. The installation of all dependencies went > fine but apparently there is an issue with grass-config. > > And just think, I'm not even finished with the ./configure process. Am I > missing something? > > Michael Allen > Industrial Weather > 763-777-1263 > > Sent with [ProtonMail](https://protonmail.com) Secure Email.___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
Thank you Markus. I suspected something like this. The version(s) of GDAL now on my computer are of the 2.4... variety. After reading through your bugzilla messages from 2018 ff. I suspected there was more to the story. Thank you. Michael Allen Industrial Weather 763-777-1263 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, December 18, 2020 2:47 AM, Markus Neteler wrote: > On Fri, Dec 18, 2020 at 5:19 AM mdwxman via grass-user > grass-user@lists.osgeo.org wrote: > > > Looks like more fun here at dog fur manor. I'm still stuck on the > > compilation of grass-7.8.5RC1 on CentOS 8. > > The script stops at line 6788 in the configure script with the ERROR > > message: Cannot find grass-config. > > This is unexpected. Do you mean > gdal-config > ? > > If yes, you need to install the "gdal-devel" RPM. > In general, also other development packages like "proj-devel" are > needed. The list is in the Wiki page cited below. > > > I've moved grass-config to many different subdirectories but always with > > the same result. > > I used the methods on > > https://grasswiki.osgeo.org/wiki/Compile_and_Install#CentOS > > under the CentOS 8 and the GRASS 7 instructions. The installation of all > > dependencies went fine but apparently there is an issue with grass-config. > > Please use to "gdal-config" as per Wiki page. > > Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8
Looks like more fun here at dog fur manor. I'm still stuck on the compilation of grass-7.8.5RC1 on CentOS 8. The script stops at line 6788 in the configure script with the ERROR message: Cannot find grass-config. I've moved grass-config to many different subdirectories but always with the same result. I used the methods on https://grasswiki.osgeo.org/wiki/Compile_and_Install#CentOS under the CentOS 8 and the GRASS 7 instructions. The installation of all dependencies went fine but apparently there is an issue with grass-config. And just think, I'm not even finished with the ./configure process. Am I missing something? Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email.___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Installation Issues on CentOS8
I noticed the issues with both the GDAL and PROJ packages. I’ve noticed that it can be difficult and sometimes impossible to find necessary packages on several Fedora repos. It makes things difficult and frustrating to install packages when even Conda can’t find necessary libraries. Michael Allen Industrial Weather 763-777-1263 On Wed, Dec 16, 2020 at 8:27 AM, Markus Neteler wrote: > Michael, > > On Wed, Dec 16, 2020 at 4:36 AM mdwxman via grass-user > wrote: >> >> I don't often compile software on CentOS but even this one has me confused. >> I'm attempting to install some version of GRASS 7.8 on a CentOS 8 box and >> I've been attempting to do so, on off for the last 6 months. > > I did the same and it was a bumpy ride. Reason: a lot of packages were > missing. I even had to become package maintainer in Fedora to push > PROJ and GDAL packages... > >> There have been several different errors and I've attempted to use conda, >> conda with a local environment using Python 3.6., yum, and DNF. There are >> two types of errors: one is the failure to find the gui (g.gui). > > The GUI issue was there till the end of November. Reason: wxpython4 > package missing, see here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1765573 > > It has finally been provided. > >> The other involves a complete stop. >> >> This time I've used the grass-7.8.0.tar.gz files from the GRASS geo site. > > Please use at least 7.8.4, soon 7.8.5 for relevant bugfixes: > > https://trac.osgeo.org/grass/wiki/Release/7.8.5-News > >> The lastest attempt results in a stop in the ./configure line at: >> >> include/Make/Vars.make:1: included/Make/Platform.make: No such file or >> directory >> >> Since it stopped I attempted to use: >> >> make: *** No rule to make target 'include/Make/'. Stop. >> >> I've installed all required libraries and other applications (I think). > > Please see here: > > https://grasswiki.osgeo.org/wiki/Compile_and_Install#CentOS > --> Centos8 > >> I am a newbie with compilers but does anyone have some help for this. >> >> The machine is a Centos 8 machine with 7 Tb disk storage and running a >> 16-core Ryzen CPU at 4125 MHz. > > THat should be perfectly fine. > >> Thanks. I hope someone can help. > > Hope the Wiki instructions help - if not, let us know. > > Markus > > -- > Markus Neteler, PhD > https://www.mundialis.de - free data with free software > https://grass.osgeo.org > https://courses.neteler.org/blog___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Installation Issues on CentOS8
Thank you Markus. I’m glad I stuck with GRASS long enough to find a solution. I’m very fortunate to discover this user group, too. As I looked through the archive for the last two years I found lots of interesting and helpful messages. One additional and brief question: in attempting to debug the script I’m curious regarding any software suggestions you might have for that task. Of course, experience & knowledge play a crucial role but any debugging software might be helpful. Any suggestions? Thanks again. Your answers uniformly provide the reasons for the errors. Many thanks. Michael Allen Industrial Weather 763-777-1263 On Wed, Dec 16, 2020 at 8:27 AM, Markus Neteler wrote: > Michael, > > On Wed, Dec 16, 2020 at 4:36 AM mdwxman via grass-user > wrote: >> >> I don't often compile software on CentOS but even this one has me confused. >> I'm attempting to install some version of GRASS 7.8 on a CentOS 8 box and >> I've been attempting to do so, on off for the last 6 months. > > I did the same and it was a bumpy ride. Reason: a lot of packages were > missing. I even had to become package maintainer in Fedora to push > PROJ and GDAL packages... > >> There have been several different errors and I've attempted to use conda, >> conda with a local environment using Python 3.6., yum, and DNF. There are >> two types of errors: one is the failure to find the gui (g.gui). > > The GUI issue was there till the end of November. Reason: wxpython4 > package missing, see here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1765573 > > It has finally been provided. > >> The other involves a complete stop. >> >> This time I've used the grass-7.8.0.tar.gz files from the GRASS geo site. > > Please use at least 7.8.4, soon 7.8.5 for relevant bugfixes: > > https://trac.osgeo.org/grass/wiki/Release/7.8.5-News > >> The lastest attempt results in a stop in the ./configure line at: >> >> include/Make/Vars.make:1: included/Make/Platform.make: No such file or >> directory >> >> Since it stopped I attempted to use: >> >> make: *** No rule to make target 'include/Make/'. Stop. >> >> I've installed all required libraries and other applications (I think). > > Please see here: > > https://grasswiki.osgeo.org/wiki/Compile_and_Install#CentOS > --> Centos8 > >> I am a newbie with compilers but does anyone have some help for this. >> >> The machine is a Centos 8 machine with 7 Tb disk storage and running a >> 16-core Ryzen CPU at 4125 MHz. > > THat should be perfectly fine. > >> Thanks. I hope someone can help. > > Hope the Wiki instructions help - if not, let us know. > > Markus > > -- > Markus Neteler, PhD > https://www.mundialis.de - free data with free software > https://grass.osgeo.org > https://courses.neteler.org/blog___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Installation Issues on CentOS8
I don't often compile software on CentOS but even this one has me confused. I'm attempting to install some version of GRASS 7.8 on a CentOS 8 box and I've been attempting to do so, on off for the last 6 months. There have been several different errors and I've attempted to use conda, conda with a local environment using Python 3.6., yum, and DNF. There are two types of errors: one is the failure to find the gui (g.gui). The other involves a complete stop. This time I've used the grass-7.8.0.tar.gz files from the GRASS geo site. The lastest attempt results in a stop in the ./configure line at: include/Make/Vars.make:1: included/Make/Platform.make: No such file or directory Since it stopped I attempted to use: make: *** No rule to make target 'include/Make/'. Stop. I've installed all required libraries and other applications (I think). I am a newbie with compilers but does anyone have some help for this. The machine is a Centos 8 machine with 7 Tb disk storage and running a 16-core Ryzen CPU at 4125 MHz. Thanks. I hope someone can help. Michael Allen Industrial Weather 763-777-1263 Sent with [ProtonMail](https://protonmail.com) Secure Email.___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
