gdal failed to build from source in Fedora rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=28439835 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild Please fix gdal at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, gdal will be orphaned. Before branching of Fedora 30, gdal will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source
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