[tre, libmagic] Windows + mingw support#17769
[tre, libmagic] Windows + mingw support#17769strega-nil-ms merged 10 commits intomicrosoft:masterfrom
Conversation
acb6ee8 to
58d81e3
Compare
There was a problem hiding this comment.
IIRC this is what I initially proposed in #17137, but it didn't seem to find acceptance.
There was a problem hiding this comment.
So now we have 2 different approaches to the same problem, let's see which one gets accepted first.
Since on MSVC triplets, uuid.lib gets stripped entirely, I'm doing the same with mingw.
|
Also, now that we have host dependencies, theoretically |
ports/libmagic/0001-Use-libtre.patch
Outdated
There was a problem hiding this comment.
pass -I"<vcpkginclude>/tre" instead of patching
There was a problem hiding this comment.
Can you help me with passing it to MSVC? No matter what I do, it doesn't seem to get through.
There was a problem hiding this comment.
Now that I think about it, MXE users will have a problem with this, since VCPKG_C_FLAGS are not passed through.
There was a problem hiding this comment.
AC_SEARCH_LIBS ! due to debug suffix on windows. Search for z zlib zlibd
There was a problem hiding this comment.
Search for
z zlib zlibd
Is this the right order for finding zlibd before zlib in debug builds?
There was a problem hiding this comment.
We don't have to worry about which one gets found first, since only one will be available in each build.
There was a problem hiding this comment.
as longnguyen2004 said. This is not cmake where we have to deal with both prefixes/libdirs being visible.
There was a problem hiding this comment.
For z, fair enough. But not in general. This is part of the "gdal completely broken on Linux" story. On Linux, there is always a system path, in addition to the debug path. And generally there is no control about the user environment (manifest mode, registries, overlay ports).
There was a problem hiding this comment.
@dg0yt We can probably uses -nostdinc/-nostdlib and manually add back in the necessary include and library paths, but that gets tedious fast.
12798c7 to
a640f58
Compare
|
What you made contains the same changes as #17137. |
|
@JackBoosY I'll keep my change here for the sake of CI, when one of them is merged I'll remove it. |
Maybe a host dependency of a non-core default feature on a non-default feature? No way to pass the tool path explicitly instead of modifying |
|
It's possible for a port to depend on itself (I just figured it out after reading the docs...)
Yeah, but that's not a problem since it's pretty straightforward, also it's the build system that needs it, not vcpkg. |
|
@Neumann-A Can you check EDIT: https://github.com/file/file/blob/03b6dcb4a24455207ef4094560c334fbc38875bd/src/file.c#L204 |
Yeah probably need to fix that + adding ${EXEEXT} in the Makefile doing the check. |
9e403d2 to
49adac8
Compare
|
Eh... |
f899987 to
4db21fb
Compare
strega-nil-ms
left a comment
There was a problem hiding this comment.
This looks good to me, just needs a minor change
|
On mingw, the build failed: |
|
@dg0yt Try applying this MSYS2 patch https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-file/0001-file-5.38-mingw-build.patch |
|
@dg0yt Is the problem solved? |
Yes, mingw build succeeds now. 👍 |
|
Now that #17137 is merged, I'll take that fix off of my PR. |
Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
45ddf7d to
9171c81
Compare
|
Alright, great, thanks for the awesome work @longnguyen2004 :) |
After a year...
Describe the pull request
What does your PR fix?
Fixes [libmagic] Clean build failure on Windows #11832
Also fixes a small bug in
vcpkg_configure_makewhereuuidisn't removed on mingw triplets.Which triplets are supported/not supported? Have you updated the CI baseline?
Windows + mingw triplets, Yes
Does your PR follow the maintainer guide?
Yes
If you have added/updated a port: Have you run
./vcpkg x-add-version --alland committed the result?Yes