`ccall()` with an absolute library path while outputting an `.o` file causes linker issues on Windows

[staticfloat]

Kristoffer and I were tracking down precompilation failures for PackageCompilerX, when we noticed a strange error coming from ld while it was trying to link together the system image:

Warning: .drectve `-export:ccalllib_C:\Users\Matthis\.julia\packages\FreeType\2dE5w\deps\usr\bin\libfreetype-6.dll,data ' unrecognized
C:/Users/Matthis/.julia/artifacts/572b61b5075459e3ed62317e674398166ca98dd4/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Cannot export FreeType: symbol not found
C:/Users/Matthis/.julia/artifacts/572b61b5075459e3ed62317e674398166ca98dd4/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Cannot export Users: symbol not found
C:/Users/Matthis/.julia/artifacts/572b61b5075459e3ed62317e674398166ca98dd4/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Cannot export ccalllib_C:: symbol not found
C:/Users/Matthis/.julia/artifacts/572b61b5075459e3ed62317e674398166ca98dd4/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Cannot export packages: symbol not found

This is being emitted as a global variable from ccall(), but appears to have some quoting issues on Windows, as the linker doesn't like the backslashes in the symbol name. We're not sure if the linker is truly to blame here, as we usually don't pass absolute library paths so we may have never actually tried to link a system image with this usage pattern before.

You can reproduce this with the following mini reproducer:

using Pkg.BinaryPlatforms

open("libfoo.c", "w") do io
    write(io, """
    #include <stdio.h>

    void foo() {
        printf("Hello, Foo!\\n");
    }
    """)
end

@info("Compiling C source...")
libfoo_fname = string("libfoo.", platform_dlext())
run(`gcc -o $libfoo_fname libfoo.c -shared`)

open("Foo.jl", "w") do io
    write(io, """
    module Foo
    const libfoo = joinpath(@__DIR__, "$libfoo_fname")
    ccall((:foo, libfoo), Cvoid, ())
    end
    """)
end

@info("Compiling Julia module...")
run(`$(Base.julia_cmd()) --startup-file=no --output-o foo.o Foo.jl`)

@info("Dumping `ccalllib` julia module symbols...")
run(pipeline(`nm foo.o`, `grep ccalllib`))

Looking at the other ccalllib symbols, they are all "soname" style:

0000000001615770 b _ccalllib_/Users/sabae/libfoo.dylib
000000000162c3d0 b _ccalllib_libcholmod
00000000016160d8 b _ccalllib_libdSFMT
0000000001615b48 b _ccalllib_libgit2
0000000001618f40 b _ccalllib_libgmp
0000000001611b50 b _ccalllib_libmpfr
000000000162ae30 b _ccalllib_libopenblas64_
0000000001623800 b _ccalllib_libopenlibm
0000000001610b60 b _ccalllib_libpcre2-8
000000000162c430 b _ccalllib_libsuitesparse_wrapper
000000000162c510 b _ccalllib_libsuitesparseconfig

[aminya]

This is the same error that I reported last year that caused the MKL building fail.
JuliaLinearAlgebra/MKL.jl#24

I posted a possible solution JuliaLinearAlgebra/MKL.jl#24 (comment), but I am not sure if it helps.

https://sourceforge.net/p/mingw-w64/mailman/message/21864960/

The problem here is the name decoration. MS doesn't extend the public 
symbols in objects by underscores, mingw-w64 does this by default. But you 
can recompile mingw-w64 crt and your app by using option 
-fno-leading-underscores. This should work.
The other solution would be, name the exported method call_me in VS 
_call_me, and reference in gcc just without the leading underscore.

[KristofferC]

This is a regression from 1.3.0 (appeared in 1.3.1) so putting on milestone. Probably #34062.

[aminya]

Can we have this backported too or not possible?

This is a regression from 1.3.0 (appeared in 1.3.1) so putting on milestone. Probably #34062.

[jwveysey]

A quick question about this issue if I could. I've been running into it while using PackageCompiler (the refactored version - dev release 1.0.0) to build a system image that includes a custom package. The process fails when gcc tries to process an import directive for a binary dependency for CodecZlib. My team was hoping to get the system image soon, so I was wondering if there's a patch I could apply to fix ccall. Would you advise trying a nightly build? Right now, I'm on Julia 1.3.1. Thanks for any pointers!

[staticfloat]

You can try this PR: #34754

[jwveysey]

You can try this PR: #34754

Thanks for the quick response. Using that PR will require building Julia myself, right? Sorry for the elementary question, but I haven't done that before. I can try following the instructions on the Julia readme, though.