wxsqlite3-5.0.1: compilation fails on Fedora 44 with undefined reference to `wxSQLite3::ResultSet::operator=(wxSQLite3::ResultSet&&)'

[martinkg]

Hi,

when compilinng version 5.0.1 on Fedora 44 i get this error message:

/usr/bin/ld.bfd: /tmp/cczuwIqD.ltrans0.ltrans.o: in function `testTransaction() [clone .cold]':
/builddir/build/BUILD/wxsqlite3-5.0.1-build/wxsqlite3-5.0.1/samples/minimal.cpp:108:(.text.unlikely+0x5c6): undefined reference to `wxSQLite3::ResultSet::operator=(wxSQLite3::ResultSet&&)'
collect2: error: ld returned 1 exit status
make: *** [Makefile:651: samples/minimal] Error 1

complete log file: build.log

Attached is a patch wxsqlite3-5.0.1-fix-resultset-move.patch that resolves this issue.

Regards
Martin

[utelle]

when compilinng version 5.0.1 on Fedora 44 i get this error message:

/usr/bin/ld.bfd: /tmp/cczuwIqD.ltrans0.ltrans.o: in function `testTransaction() [clone .cold]':
/builddir/build/BUILD/wxsqlite3-5.0.1-build/wxsqlite3-5.0.1/samples/minimal.cpp:108:(.text.unlikely+0x5c6): undefined reference to `wxSQLite3::ResultSet::operator=(wxSQLite3::ResultSet&&)'
collect2: error: ld returned 1 exit status
make: *** [Makefile:651: samples/minimal] Error 1

This is really strange, because the class definition of ResultSet has the move assignment defined as

ResultSet& operator=(ResultSet&&) = default;

So, the move assignment operator is defined. It may be a problem with the GCC-LTO processing. Could you try to build with compile time flag -fno-lto? If the problem vanishes, that would identify LTO as the root cause.

Alternatively, you could try to just deactivate function splitting using -fno-reorder-blocks-and-partition.

You could also try to compile with an older GCC version - it might be a regression in GCC 16.

Finally, you could try to compile after adding the following lines in wxsqlite3.cpp:

namespace
{
  volatile auto force_link_ResultSet_move_assign =
       static_cast<ResultSet&(ResultSet::*)(ResultSet&&)>(&ResultSet::operator=);
}

This could be a workaround until the real problem in GCC is fixed.

Attached is a patch wxsqlite3-5.0.1-fix-resultset-move.patch that resolves this issue.

In principle, it works of course to introduce a separate ResultSet instance. But that should really not be necessary.

[martinkg]

disable GCC-LTO for wxSQLite3 something like this was enough to get it to compile again.

export CFLAGS="%{build_cflags} -fno-lto"
export CXXFLAGS="%{build_cxxflags} -fno-lto"

[utelle]

disable GCC-LTO for wxSQLite3 something like this was enough to get it to compile again.

export CFLAGS="%{build_cflags} -fno-lto"
export CXXFLAGS="%{build_cxxflags} -fno-lto"

That verifies that it is a GCC problem. It seems not to be restricted to the latest GCC version, because I made a test under Ubuntu with GCC 13 adding the flag -flto=auto - and I got the same error as you. Maybe it should be reported to the GCC developers.

[utelle]

Could you please provide exact version information about the GCC compiler you used? I intend to make a bug report to the GCC developers. TIA.

[martinkg]

# gcc --version
gcc (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2)
Copyright (C) 2026 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# uname -a
Linux fc44 7.1.8-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Aug 10 03:35:23 UTC 2026 x86_64 GNU/Linux

[utelle]

Thanks for the compiler information.

Unfortunately, it isn't easy to file a GCC bug report. I need an account for the GCC buzilla system first. I requested it, but I have no idea how long it will take to get it.

Additionally, I saw on the GCC bug list about 400 reports related to LTO, most unassigned, many several years old. This dampens hopes for a quick resolution of the problem. Therefore I added the workaround that solved the problem on my Ubuntu system to the wxSQLite3 code base.

If you have time, I'd appreciate it if you could test whether this fix resolves the issue on your Fedora system as well.

[martinkg]

compiles fine on Fedora with your changes:
09fed84068a67f85defd9c209682ca472b76b065.patch

[utelle]

compiles fine on Fedora with your changes:

Thanks for testing and reporting!

[utelle]

Just for completeness: I made a gcc bug report (Bug-Id 127003) today.