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 <[email protected]> wrote:
> On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user
> <[email protected]> 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
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-user
