Sqlx: Error compiling sqlx-macros v0.4.0-beta.1 in stable pc-windows-gnu

[yorodm]

I'm using rustc 1.45.2 and gcc (Rev2, Built by MSYS2 project) 9.2.0 on windows 10. The error is related to linking sql-macros

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: export ordinal too large: 70242
          collect2.exe: error: ld returned 1 exit status

[yamashi]

Have you ever found a solution?

[julientregoat]

I'm experiencing a similar issue in the same environment, sqlx failing to compile due to a linking error error: linking withx86_64-w64-mingw32-gccfailed: exit code: 1 - but slightly different output.

          libsqlite3-sys-0.20.1/sqlite3/sqlite3.c:46507: undefined reference to `__errno'
          target\debug\deps\liblibsqlite3_sys-1b247c2df61709cc.rlib(sqlite3.o): In function `winFullPathname':
          libsqlite3-sys-0.20.1/sqlite3/sqlite3.c:47270: undefined reference to `cygwin_conv_path'
          libsqlite3-sys-0.20.1/sqlite3/sqlite3.c:47274: undefined reference to `__errno'
          libsqlite3-sys-0.20.1/sqlite3/sqlite3.c:47292: undefined reference to `cygwin_conv_path'
          libsqlite3-sys-0.20.1/sqlite3/sqlite3.c:47296: undefined reference to `__errno'

[julientregoat]

I was wrong actually, my error also notes the same exact issue as OP in addition to the above log, I must have missed it:

error: export ordinal too large: 72082

EDIT: found some more information on this error from the msys people - https://github.com/msys2/MINGW-packages/pull/6463#issuecomment-626128290

[Malanche]

Hello,

I have been trying to find the issue here, but it just seems like the sqlx-macros ends up exceeding the 16-bit name symbol limit in Window's dlls files (this issue does not occur with mingw <= 6.4.0, where it actually manages to create the dll file under target/debug/deps, in my case weighting a whopping 78MB, outweighting every other dll and lib file in such folder). But anyways, if the dll gets generated, the build fails when trying to compile the sqlx crate, with an (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION) error. I have not been able to pass this point. I will read a bit the internals of the sqlx-macros crate to see where the >65k symbols are comming from, and any findings I will write here back

[abonander]

I'm benchmarking a change that forces the proc macros to compile with optimizations on, when I open the PR I'd like someone to try building with my branch to see if it fixes this error as well.

[Malanche]

I'm benchmarking a change that forces the proc macros to compile with optimizations on, when I open the PR I'd like someone to try building with my branch to see if it fixes this error as well.

Sorry if I am being a bit naive but that would work only if cargo build --release worked, no? As this turns on optimizations for each crate... In my case, the symbol count goes down from 68,162 to 67,900 when using the --release flag. Anyways, I am happy to try building the branch to see if it works.

[abonander]

Sorry if I am being a bit naive but that would work only if cargo build --release worked, no?

No, because proc macros and build scripts are _always_ built in debug mode. This is likely done under the assumption that the compiler would spend more time optimizing the build script/proc-macro than the time it will take for the proc-macro to execute. SQLx's macros unfortunately break this assumption since they come with so much baggage (an async runtime).

Unfortunately, as it turns out, the only way to force the proc macros to compile with optimizations on is to force _all_ build dependencies (build scripts and proc macros) in the dependency tree to compile with optimizations on: https://doc.rust-lang.org/cargo/reference/profiles.html#build-dependencies

Using [profile.dev.package.sqlx-macros] does not seem to affect how the proc macros are compiled. Because of this, I'm hesitant to default-override this option for _all_ build-dependencies because it might well make compilation slower for some people.

So @Malanche if you want to try the fix, you can add the following to your project's Cargo.toml:

[profile.dev.build-override]
opt-level=3
codegen-units=1

In my testing I found that it improved compilation times when using SQLx's macros by ~25% (building tests/postgres/postgres-macros.rs) but also forced a full-rebuild of the dependency tree the first time (thus implying that it changes the option for all dependencies).