[GRASS-user] More Fun Compiling & Installing GRASS on CentOS 8

[mdwxman]

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 <neteler at osgeo.org> wrote:

> On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user
> <grass-user at 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20201219/6160f8b9/attachment-0001.html>