mirror of https://github.com/postgres/postgres
The fundamental problem is that when we call clang to generate bitcode, we might be using configure results from a different compiler, which might not be fully compatible with the clang we are using. In practice, clang supports most things other compilers support, so this has apparently not been a problem in practice. But commitsmaster4cfce4e62c,0af05b5dbb, and59292f7aachave been struggling to make typeof_unqual work in this situation. Clang added support in version 19, GCC in version 14, so if you are using, say, GCC 14 and Clang 16, the compilation with the latter will fail. Such combinations are not very likely in practice, because GCC 14 and Clang 19 were released within a few months of each other, and so Linux distributions are likely to have suitable combinations. But some buildfarm members and some Fedora versions are affected, so this tries to fix it. The fully correct solution would be to run a separate set of configure tests for that clang-for-bitcode, but that would be very difficult to implement, and probably of limited use in practice. So the workaround here is that we hardcodedly override the configure result under clang based on the version number. As long as we only have a few of these cases, this should be manageable. Also swap the order of the tests of typeof_unqual: Commit59292f7aactested the underscore variant first, but the reasons for that are now gone. Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/92f9750f-c7f6-42d8-9a4a-85a3cbe808f3%40eisentraut.org
parent
be0d0b457c
commit
63275ce84d
Loading…
Reference in new issue