Skip to content
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

Fix compilation under Windows with MinGW #266

Merged
merged 2 commits into from
Jul 30, 2019
Merged

Fix compilation under Windows with MinGW #266

merged 2 commits into from
Jul 30, 2019

Conversation

nxrighthere
Copy link
Contributor

The compiler-specific condition for type and cat is incorrect. Also <io.h> is missed for _get_osfhandle.

@nxrighthere
Copy link
Contributor Author

What's wrong with the Jenkins? The first commit with WIN32 didn't pass the build, the second is pending for almost 5 hours.

@shibatch
Copy link
Owner

@nxrighthere Thank you for your commit!
I am sorry, but Jenkins is not working properly now, due to expiration of emulator.
I will fix it soon.

@shibatch shibatch merged commit 7f523de into shibatch:master Jul 30, 2019
@yuyichao
Copy link
Contributor

I'm not sure what's the correct condition but this breaks my compilation under msys2 using makepkg-mingw for mingw64 ....

@nxrighthere
Copy link
Contributor Author

On which OS?

@yuyichao
Copy link
Contributor

Windows 10

@yuyichao
Copy link
Contributor

This was the PKGBUILD (the master branch has one additional patch to revert this change).

The build.make has a line like type C:\X\Y\Z >> ... and the type gives an error about not being able to fine C:XYZ.

@nxrighthere
Copy link
Contributor Author

I think the condition should be then if(MSVC OR MINGW AND WIN32 AND NOT MSYS) to separate standalone MinGW and the one under MSYS2.

@yuyichao
Copy link
Contributor

yuyichao commented Nov 10, 2019

That should cover my case for sure.

However, I don't really use windows (edit: and the PKGBUILD above was for my lab...) and have no idea what's the difference between all these posix like environment for windows so I can't say what should be the correct logic ...... = = ....

@nxrighthere
Copy link
Contributor Author

If you use the standalone MinGW then cat is not available since it's a UNIX utility and type works just fine. In your case I think cat is available under MSYS2 so we just need to separate the two.

@yuyichao
Copy link
Contributor

Sounds fair. What I mainly don't understand is why does type not work for me if it works with the standalone mingw.

@nxrighthere
Copy link
Contributor Author

Good question, I'm not using MSYS2, so can't explain where the problem is.

@yuyichao
Copy link
Contributor

In particular, for me, the build.make was executed by /bin/sh, which use the shell builtin type command rather than the windows cmd command (the error message for file not found are different and the shell builtin one also doesn't support C:\... paths somehow...). The command line argument given to it is also escaped incorrectly causing all the \ to be missing from the file name....

I just tried using the mingw-w64-x86_64-make package instead of the make package for the make (mingw32-make) command and it didn't make a difference..... (they both pick up /bin/sh)

@shibatch
Copy link
Owner

One solution could be to build a command for displaying the content of a file from a source code.
I tried to do that before, but this proposal was rejected.

#138

yuyichao added a commit to yuyichao/sleef that referenced this pull request Jul 9, 2021
Similar to 75b62aa (shibatch#396) for better support of MinGW.

This fixes the regression caused by shibatch#266 when building for mingw under msys2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants