I am the MariaDB & MySQL stack maintainer.
I’m working on the new rebase of MariaDB (10.5.22).
The new version produces ‘internal compiler errors’ on i686.
And frankly, I believe that dropping the i686 architecture is way more effective than debugging the issue.
Since we don’t support installations of i686 Fedora (for quite some time already), and I’m not sure whether 32-bit installation is now possible at all (AFAIK we don’t build i686 kernel anymore), the only reason I can see to keep building i686 packages if beacuse of libraries 32-bit-only applications could be built on.
In case of MariaDB, we use a separate package, called ‘mariadb-connector-c’ which holds the client library. Unless you are building a MariaDB server module, you don’t need the MariaDB server library devel files. So apart of this rare use-case, everyone is expected to build only against the client library.
I don’t plan to drop i686 builds of the ‘mariadb-connector-c’ package.
Moreover, as I don’t expect people casually running 32-bit build of the DB, where 64-bit is available, I see the i686 builds as enormous waste of precious KOJI resources, as DBs are one of the biggest chunks of software we have, taking hours to compile (now multiply by number of Fedora releases, and by number of scratch-builds done before production build).
So, is it okay, to drop the i686 builds of package ‘mariadb’ ?
Or are there some i686 usages I’m not aware of ?
You will have to get consuming packages to stop building for i686 as well, or drop mariadb support on i686. I started looking through the list of consuming packages (see the output of “dnf --repo=rawhide --repo=rawhide-source repoquery --whatrequires mariadb-connector-c-devel --alldeps”). I’ve looked at a dozen, and so far haven’t found a single one that doesn’t build for i686. This includes some pretty important packages, such as bind.
In the short term, you should file a bug on gcc about the internal compiler errors. The gcc team is usually pretty quick to fix those.
Thank you Jerry for looking into it.
Based on what I described - that I’d like to stop building i686 variant of package ‘mariadb’, but keep building i686 variant for package ‘mariadb-connector-c’, shouldn’t the correct list of packages to be checked be:
dnf --repo=rawhide --repo=rawhide-source repoquery --whatrequires mariadb-devel --alldeps
dnf --repo=rawhide --repo=rawhide-source repoquery --whatrequires mariadb-connector-c-devel --alldeps
I’ll report the internal compiler error to the GCC team in the meanwhile, that’s a great suggestion, thanks.
Oh sorry, I read your original post too quickly. You’re quite right about the list of packages. I’d bet that some of those, such as Macaulay2, don’t need the server package and should be built against mariadb-connector-c instead.
Your assessment of i686 usage in Fedora is correct.
Basically, only Wine and Steam need and use the i686 libraries.
Unless your library is needed by either of those,
you are allowed (and encouraged) to exclude i686,
But, to avoid build failures,
you have to start from leaf packages and work up the tree from there.
So the way would be to figure out the full tree of dependees
and submit a pull request to each, in correct order, adding
You may also hit a problem where the “comps” that define which i686 packages are included in the Fedora package repositories refer to one of the packages,
even if they are not actually needed there.
In that case, you get to update the comps.
I think they come from this Git repository: pagure.io/fedora-comps.
Often, when there are more than a couple of dependeess, this procedure is too burdensome,
and thus i686 leaf removal is not progressing very quickly.
For details, see Fedora 37 Change: Encourage i686 Leaf Removal.