msys/ mingw64 failing at linker step #1133
Labels
Comments
|
What linker does mingw use? If it’s MSVC’s LINK.EXE there’s different flags to set. If it’s not there’s probably still different flags to set. Or the Postgres sources fail to properly exposer those symbols under windows? That’d be weird tho. I’m sure they solved that problem 15+ years ago. |
|
What does: "-C link-arg=/FORCE" do for the rustflags? I think that’s the correct syntax for LINK.EXE. I had that filed away in my brain for something I did years ago. https://learn.microsoft.com/en-us/cpp/build/reference/force-force-file-output |
I tried that first and got an error. forgot to mention that. I seem to be making some progress though, now I seem to be getting only plpgsql link errors. I had added this to pgrx/pgrx-pg-sys build_shim So now just getting link errors like: I'm going to try to add plpgsql to see if that clears those. |
|
We've never linked in libpq before. Why would it be required for windows? I can't see any reason for pgrx to need to link to the client library. And afaik we haven't done anything special for for the plpgsql symbols, such as |
|
Okay this might be my mistake. Looks like I added postgres dependency to pgrx-pg-sys trying to fix linking errors earlier and I see that's not in current Cargo.toml. Maybe that's what dragging that in. I'll try taking that out to see what happens in a bit. |
|
I don't think it was my inclusion of postgres extension. I took that out and still have issues even after cargo clean. I also confirmed the https://github.com/sfackler/rust-postgres/ project actually compiles and runs fine under my msys/mingw64 setup. It fails some tests, but those are expected since they are testing extensions like hstore and ltree I didn't bother compiling. But one thing I notice, yes I get fewer complaints about missing symbols when I explicitly add in postgres and libpq libraries as mentioned before, I read here https://users.rust-lang.org/t/export-ordinal-too-large-error-while-linking/74547/8 might be a bug in mingw64 linker. Other suggestion is reduce size of dll or reduct number of exports. which is maybe why even adding the pgsql to list doesn't help as it's run out of room Usually to get around these link issues I have my LDFLAGS I tried putting that in, but didn't help anyway my compile looks like this before it crokes on the export ordinal too large: 193557 and plpgsql errors |
|
Hm, that's probably not the right approach, let me look and see if there's a better solution to your problem. (Note that |
|
@thomcc Thanks. Any thoughts are welcome |
|
Hm, yeah, I got stuck here, sorry. How do you import the symbols in C? If not perhaps we need to use raw_dylib, but as C has no equivalent, I'd assume some import lib exists |
|
Usually adding to my LDFLAGS something like does the trick. lib is the folder that contains all the extension libraries and libpq.dll, libpostgresq.a, libpgport.a etc. I'm not sure where I can put that -L/path/to/postgresql/lib . One thing I notice is rust is introducing other things to LDFLAGS and trying to remove them doesn't seem to work, so I'm thinking its some additional things it's adding that is conflicting with what I'm trying to add. I forgot how I saw that. I'll try to rerun again to see the full output it is using for LDFLAGS |
|
So one trick to customize linking for rust is to make a little python (or whatever) program that you set as the linker, which then gets set as If this sounds abstract, when I worked at mozilla we did that in servo here and in rust-android-gradle here (both of these uses are Android for various reasons having to do with the bionic linker being annoying, but it would work fine for your case too, you'd just need to forward to link.exe). I'm not sure if that helps you any, but that's generally the solution to "damn, rustc is sending the wrong flags to the linker"-style problems. |
|
Actually, if you have access to a dll of a C extension built in this manner, and can use dumpbin to dump its imports (see https://learn.microsoft.com/en-us/cpp/build/reference/imports-dumpbin?view=msvc-170 -- don't provide the filter for import source, just Basically, I suspect Footnotes
|
|
Just in case you need it, since I had to use my VS install to use dumpbin. Here is the output of
https://gist.github.com/robe2/6f0fdf660d938a29672786a722994f63 Using mingws objdump too https://gist.github.com/robe2/b08eb86f424f64052e06316102c66b4f |
|
Just occurred to me I didn't compile hstore with --enable-auto-import, though I think somewhere in postgresql code it does have that logic in there for windows. Here is another extension (packaged with postgis (though just has a dependency on pcre) ) where my configure does have -enable-auto-import for sure, and seems to import different set of symbols.
https://gist.github.com/robe2/5b1e2a4d7bd84154add7d09e85134301 For the postgresql contrib extensions, I don't think I've ever had to do that at least not for a while. I didn't follow what you said about CARGO_TARGET_X86_64_PC_WINDOWS_GNU_LINKER but maybe when I read those files you linked to it will be clearer. |
|
I found out the solution here. We need to either:
So, this is not really trivial to fix, but it is far from impossible. I may be getting a nice windows machine in the next few months, and if I do so I might hack something for this together over a weekend. Note that all of this assumes that there's no Note mostly for my own reference in the future, https://github.com/lucasg/Dependencies can be used to help track this stuff down. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not sure if this is related to #731, but I got to this point trying to get to work under mingw64 and changing the test files.
Everything goes up to here (cshim or no shim doesn't matter too much)
and then fails with a slew of linker errors, which look mostly looking for postgres functions.
I tried changing the .cargo/config.toml to have line
Also tried:
Any thoughts on what I could try next will be much appreciated.
The text was updated successfully, but these errors were encountered: