You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR fixes some Windows compilation issues I found when compiling with GCC on Windows (MinGW64/MSYS2 specifically in my case):
Turns some WIN32 checks into more-accurate MSVC-specific checks using _MSC_VER variable. These should not affect compilation with MSVC.
Remove -lrt from the linked libraries (doesn't really exist for Windows, AFAIR), and add the -lshlwapi library because abc uses PathMatchSpecA somehow.
ABC's link command-line has unfortunately gotten large enough that it exceeds the 32768-or-so character limit on the command-line. The workaround is ResponseFiles- i.e. supply the command-line arguments via a dynamically-generated file. I use GNU Make's file function for this; the docs even state that response files are an intended usage :D.
At least in the case of MinGW, uname -s isn't necessarily static (it appends a version string, which can vary between systems). I bring in code from yosys to make the OS variable remain the same between systems.
I mainly follow the yosys branch of ABC, so I was able to compile abc without issue until a recent merge. By looking at the yosys branch and main side-by-side (git log --all --decorate --oneline --graph), it seems all the commits that required me to make these changes were between 68c576c and now (9c41da6).
I mainly follow the yosys branch of ABC, so I was able to compile abc without issue until a recent merge. By looking at the yosys branch and main side-by-side (git log --all --decorate --oneline --graph), it seems all the commits that required me to make these changes were between 68c576c and now (9c41da6).
Hi, I'm not on windows but have you tried git bisect XXX to locate the exact commit that causes the issue?
Hi, I'm not on windows but have you tried git bisect XXX to locate the exact commit that causes the issue?
No, I didn't bisect because there isn't a single commit that corresponds to the issues this PR fixes. Additionally, the 32768 character problem is just going to keep coming back, now that the link command is approximately large enough.
I updated this for latest master and latest Github runners, and submitted as PR #492.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes some Windows compilation issues I found when compiling with GCC on Windows (MinGW64/MSYS2 specifically in my case):
WIN32checks into more-accurate MSVC-specific checks using_MSC_VERvariable. These should not affect compilation with MSVC.-lrtfrom the linked libraries (doesn't really exist for Windows, AFAIR), and add the-lshlwapilibrary becauseabcusesPathMatchSpecAsomehow.filefunction for this; the docs even state that response files are an intended usage :D.uname -sisn't necessarily static (it appends a version string, which can vary between systems). I bring in code fromyosysto make theOSvariable remain the same between systems.I mainly follow the
yosysbranch of ABC, so I was able to compileabcwithout issue until a recent merge. By looking at the yosys branch and main side-by-side (git log --all --decorate --oneline --graph), it seems all the commits that required me to make these changes were between 68c576c and now (9c41da6).