-
Notifications
You must be signed in to change notification settings - Fork 282
MinGW version of pysam #1274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
MinGW version of pysam #1274
Conversation
Pysam seems to be working at least under MSYS2 shell.
Benchmark had some errors.
|
Couple of fixes to get pysam compiling on Linux
Couple more fixes for Linux
Please add a Windows build to the job matrix in .github/workflows/ci.yaml so that we can see this build in operation. |
Looks like I have no idea how to get the build job working nor do I have the time to learn to do so at the moment. |
Currently hacking away at this myself-the issue I'm running into running it under msvc python is that the cython extensions use posix-isms which...is not something you're really allowed to do. Seeing if I can't work around it. edit: its kinda worse than that-the shared model doesn't quite work because you can't link a .a output from gcc using cython/msvc. |
I think pysam needs major patching to work with MSVC and/or clang-cl. There is a MSVC port of htslib and that might be a good starting point. https://github.com/refresh-bio-sandbox/htslib-msvc/tree/develop |
the other way to go about doing it would be to use something like CMake's GNUToMS and to link it as such-probably easier, honestly. edit: and as luck would have it htslib's makefile already spits out a .lib if you use build-shared |
Okay, so I was mostly getting around portability issues with simple find-replace and a few mingw headers (mostly strcasecmp/_stricmp and STDIN_FILENO/ _fileno(stdin) alongside some symbol changes (specifically the data variable exports from htslib get mangled) and this worked until I ran into samtools coverage.c. Apparently msvc doesn't support VLAs. Because why would it? Gonna be a more involved port than I'd like. |
If you can, please share your progress on Github or elsewhere. |
Oh i will, don't worry.
…________________________________
From: teepean ***@***.***>
Sent: Tuesday, March 18, 2025 2:07 PM
To: pysam-developers/pysam ***@***.***>
Cc: Andrew Robbins ***@***.***>; Comment ***@***.***>
Subject: Re: [pysam-developers/pysam] MinGW version of pysam (PR #1274)
If you can, please share your progress on Github or elsewhere.
—
Reply to this email directly, view it on GitHub<#1274 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACFNSCLC3UA3XNYNY737BXL2VBOFPAVCNFSM6AAAAABRH2AKW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMZUGI3TINBQGI>.
You are receiving this because you commented.Message ID: ***@***.***>
[teepean]teepean left a comment (pysam-developers/pysam#1274)<#1274 (comment)>
If you can, please share your progress on Github or elsewhere.
—
Reply to this email directly, view it on GitHub<#1274 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACFNSCLC3UA3XNYNY737BXL2VBOFPAVCNFSM6AAAAABRH2AKW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMZUGI3TINBQGI>.
You are receiving this because you commented.Message ID: ***@***.***>
|
AFAIK clang-cl supports VLAs. |
Most likely I will only be interested in merging an MSYS2-based approach such as @teepean's. What you're describing for MSVC support is too invasive for a niche platform. |
the primary issue there is that msys2-based python is...not widely used. the goal if i can get this to work is for it to be minimally invasive, don't worry! |
AIUI MSYS2 produces native executables without unusual dependencies. If this is the case, or if pysam uses delvewheel when building wheels, this is irrelevant. |
I might be operating on outdated information here but my understanding was that python extensions proper need to link the pythonXY.lib file for MSVC python, which isn't impossible, just a pain. Will keep posted. edit: actually this may be easier than i thought |
okay, the good news is that i have it building against MSVC python w/ no major modifications. the bad news is... `ModuleNotFoundError: No module named 'pysam.libchtslib' |
With MinGW builds this means that the module cannot find all of it's dependencies. |
yeah, I checked that. Delvewheel and all. No dice
|
https://github.com/theAeon/pysam/tree/pysam-mingw if you want to give it a try |
Any instructions on how to build this one? |
|
This produces a build with gcc not MSVC or am I missing something here? |
linked w/ msvc python |
In that case the resulting pyds depend on ucrt64 dlls. |
which i put in the wheel with delvewheel (specifically give it a go, it won't work |
I built pysam accidentally with clang64 instead of ucrt64 but decided to go with that. Here's the delvewheel version. Basic functionality seems to be working. https://drive.google.com/file/d/1c9vpNIpwWtFVkLdQxFoXs-wcaIKPoodg/view?usp=sharing |
Here's a test log. https://gist.github.com/teepean/d50974cffa9f0a4f38da99958eaa70ab |
Huh. Wonder why it wasn't working on end. |
You mean why it wasn't working on your end? Did you test the whl I linked earlier? |
On my end-and I was referring to my delvewheel run. I'll give that a try shortly. |
bizarre |
I am using official Python 3.13.1. I am going to upgrade and see what happens. |
Works just fine. You could use Procmon to see which one of the DLLs is not found. |
It loaded, but only after my pysam.libs folder was made to look like this. Probably safe to write off as something wrong with my install. Probably.
|
oh, its way stupider than that. there was an extra hts-3.dll in pysam/ that wasn't getting deleted by pip uninstall and was messing everything up. disregard. let me fix ci while i'm at it |
Build tested on MSYS2 ucrt64 environment.
Test results: