Created attachment 1469489 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Created attachment 1469490 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1469491 [details]
state.log

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

The supposed fix for this didn't work, it's still FTBFS. I can see why Devrim thought just adding BuildRequires: gcc-c++ should fix this - it looks a lot like https://trac.osgeo.org/gdal/ticket/4436 - but even with that BuildRequires added (and I verified gcc-c++ really gets installed to the buildroot), the build fails with the "unable to infer tagged configuration" error...

For reference: Building the latest version of gdal does not solve the problem.

https://koji.fedoraproject.org/koji/taskinfo?taskID=29074138

--tag was removed from GDALmake.opt.in again in the same year (2012). What was added though in April of this year, is --silent. But that's not causing it.

Right, but the point of that ticket is, it turned out that the problem was happening in that case because configure was run without gcc-c++ installed. So it sure would seem to make sense that we had the same problem, and adding BuildRequires: gcc-c++ would fix things! Turns out it didn't, though.

The problem is caused by line 361 of the spec file:

sed -i 's|@LIBTOOL@|%{_bindir}/libtool|g' GDALmake.opt.in

Instead of using the libtool script generated by ltmain.sh, the spec file is ignoring it and using /usr/bin/libtool.  That's wrong.  If you remove that line from the spec file, then the generated libtool script successfully produces the necessary --tag=CXX argument without any further assistance, because that is the only valid tag.

/usr/bin/libtool says:
available_tags='CXX F77 FC GO GCJ RC ' (so you have to say which tag you want)

generated libtool script says:
available_tags='CXX ' (there is only one tag, so that must be the one we want)

This spec file needs some TLC.  It has "rm -rf %{buildroot}" as the first line of %install, which should be removed.  It uses "%add_maven_depmap", which is deprecated.  It has license files listed under %doc instead of %license.  It could use the %py3_build and %py3_install macros to simplify things a bit.  There is probably more; that's what I saw just glancing through.

Also, after fixing the libtool problem, the build still fails due to bugs in %install.  First, lines 572-574 of the spec file say:

#TODO: Don't do that?
find %{buildroot}%{perl_vendorarch} -name "*.dox" -exec rm -rf '{}' \;
rm -f %{buildroot}%{perl_archlib}/perllocal.pod

The failure is:

+ find /builddir/build/BUILDROOT/gdal-2.3.1-2.fc30.x86_64/usr/lib64/perl5/vendor_perl -name '*.dox' -exec rm -rf '{}' ';'
find: '/builddir/build/BUILDROOT/gdal-2.3.1-2.fc30.x86_64/usr/lib64/perl5/vendor_perl': No such file or directory

That's because those files were installed into /usr/lib instead of /usr/lib64.  Also, there is an empty directory named /builddir/build/BUILDROOT/gdal-2.3.1-2.fc30.x86_64lib/python3.7/site-packages.  Note the absence of "/usr".

Thanks for the analysis, I'll try to fix the FTBFS now at least.

WIP PR https://src.fedoraproject.org/rpms/gdal/pull-request/7