mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #53] How to build libxlsxwriter on Windows with MinGW-w64? #43
Labels
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#43
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @silvioprog on GitHub (Jun 22, 2016).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/53
Hello,
First, thanks for this awesome library, I've tested it on my Xubuntu and I'm impressed with its quality!
So, I'm trying to build
libxlsxwriter(latest release, 0.3.8), but I'm not sure about my steps, that was:The result:
And the
log.txtcontent:So, can I build libxlsxwriter with MinGW-w64 on Windows? If so, which commands I need perform?!
Thank you!
@jmcnamara commented on GitHub (Jun 23, 2016):
Hi Silvio,
I haven't built libxlsxwriter on MinGW (I have with Cygwin64) so I can't provide you with exact commands to get it to work.
One thing I noticed in the log that looks odd is that the compiler is trying to use the
_open_zipfile_win32()function in packager.c. That function should be MSVC specific since it is included in with a_WIN32define.Do you know if MinGW also defines
_WIN32? If it does you could try changing it to something undefined in the code to see if the compilation works.John
@jmcnamara commented on GitHub (Jun 23, 2016):
According to the following it looks like MinGW does define
_WIN32: http://stackoverflow.com/questions/9025708/mingw-not-defining-win32-error-in-preprocessor-directivesWhether that is valid or not I don't know. Try changing this code in packager.c
To just:
There is one other section of code in a
_WIN32define in the same file that you can remove if necessary.@silvioprog commented on GitHub (Jun 23, 2016):
Hello @jmcnamara
So, I can use
cygwin, do you have some doc showing the steps to build on that?The
libxlsxwriteris a very useful library, it should provide compiled binaries (.dll) for Windows and tar.gz for Linux.@silvioprog commented on GitHub (Jun 23, 2016):
I got some progress with
cygwin. Now the error is related toioapi:I tried it too:
Got same error. I'm not sure what library I need to link ...
@silvioprog commented on GitHub (Jun 23, 2016):
Hm... it seems
makegenerates .so intead of .dll:I want to build on Windows just do get the
libxlsxwriter.dll. :-/@jmcnamara commented on GitHub (Jun 23, 2016):
Hi,
Here are the changes I made to the makefiles to get it to build in cygwin. Note, I don't know if the output dll (in the lib dir) is valid but the
.afile is and the example programs compile and run within cygwin.@silvioprog commented on GitHub (Jun 23, 2016):
I'm going to try it on
cygwinandmingwtoo ...@silvioprog commented on GitHub (Jun 23, 2016):
I forgot to ask about 32 bits... can I generate a 32bis libxlsxwriter.dll?
@jmcnamara commented on GitHub (Jun 23, 2016):
I haven't done it but it should be possible.
@silvioprog commented on GitHub (Jun 23, 2016):
Bro, I have bad news. :-( It fails in:
Now I'm going to try Visual Studio, the only problem is because it needs 8GB free disk and a lot of time to be installed via web (the internet speed here in Brazil is very bad), so I don't know when I'll back with some feedback. :-(
The libxlsxwriter really should compile on MinGW-w64 (with something like
./configure && make && make install-strip), it is very easy to be installed and don't need a lot of free disk space. I use many libraries (libuv, libmicrohttpd, libharu, etc.), all compiled on MinGW installed via this official setup. My C/make knowledge is very begginer, but I'm trying to help to build libxlsxwriter and hoping to see it in the official documentation: "Buildind libxlsxwriter with MinGW on Windows". :-)@Alexhuszagh commented on GitHub (Jun 23, 2016):
I have the exact same issue in MSYS2, which is a 64-bit Cygwin-like environment that builds to DLLs (so it does not need a Cygwin environment for releases).
However, a cursory look shows the following:
I was able to fix packager.c with two preprocessor directives, both identical, as follows:
The first is on line 27, the second on line 88. It compiles fine afterwards. Hopefully this can be patched in the master, since it should be MinGW/Msys2 specific.
There is, however, one more error. The extension of the dynamically linked library, which should be ".dll", is ".so", but the actual file is a DLL.
I might look at packager.c to see if I can fix this.
@Alexhuszagh commented on GitHub (Jun 23, 2016):
Quick confirmation that a program linked to the patched file compiles, links and executes fine on my system.
Thanks for the excellent library jmcnamara.
@silvioprog commented on GitHub (Jun 23, 2016):
@Alexhuszagh thanks for share this informations. I'm away from my development PC, but I'll try this new steps, I really I'll avoid to download Visual Studio. Thanks again! :-)
@silvioprog commented on GitHub (Jun 23, 2016):
I agree @Alexhuszagh . The libxlsxwriter is awesome, I want to share it in many places like social network, programming groups/forums, university, work etc. :-)
@jmcnamara commented on GitHub (Jun 23, 2016):
@Alexhuszagh thanks. I'm working on some fixes for the mingw and cygwn issues.
@Alexhuszagh commented on GitHub (Jun 23, 2016):
@silvioprog Yeah, I've used XlsxWriter (his Python package) forever, and was amazed he also has a C/C++ library as well.
And @jmcnamara let me know if I can test anything, since I have a lot of redundant build systems (msys2, mingw, and Cygwin) in place.
@jmcnamara commented on GitHub (Jun 23, 2016):
I've pushed fixes for MinGW and Cygwin to the master branch. They are working in the 2 envs I have for testing.
They should compile without modification or warnings but let me know if you see anything.
@silvioprog commented on GitHub (Jun 23, 2016):
YYYEEESSS!!! \o/
@jmcnamara you fixed the problem! I saw the latest commit (
be0097b717), so after update my repo and rebuild the library, finally I got thelibxlsxwriter.dllabout 750KB, but after strip it only 214KB. I can send a patch to declare the make optioninstall-strip.Now, the only command is:
And the magic happens! :-)
Two observations:
gccinstead ofcc;All my steps to build the library from scratch (we should update the documentation showing the steps to build
xlsxwriteron MinGW, because it can be very useful for begginers.):The make log:
@silvioprog commented on GitHub (Jun 23, 2016):
@jmcnamara oops, I just see your message now! ^^'
I'm going to re-update and re-build it now ... :-D
@silvioprog commented on GitHub (Jun 23, 2016):
@jmcnamara I did some changes in the makefiles that chooses the
gcccompiler and declares theinstall-stripanduninstalloptions, can you check this attached patch? If so, feel free to change it, because I'm not sure if thegcccan be the default compiler in the makefiles.Unfortunatelly I still see many warnings during compiling, but I get the compiled DLLs. Anyway, thanks a lot for this great library and your effort maintaining that, now I'll share xlsxwriter in many places. :-)
0001-Fixes-for-gcc.patch.txt
@jmcnamara commented on GitHub (Jun 24, 2016):
I fixed the warnings and the CC issue.
@jmcnamara commented on GitHub (Jun 24, 2016):
I also added
uninstallandstripmakefile targets but notinstall-stripsince not everyone will want to install stripped versions of the binaries and it can be made up from the other 2.@silvioprog commented on GitHub (Jun 24, 2016):
In only one word: P.E.R.F.E.C.T!
Now, we just:
If you prefer, I can send a patch to update the Installation on Windows using Microsoft Visual Studio, adding something like Installation on Windows using MinGW-w64, showing the steps I sent. I'm glad contributing this project in some way.
@jmcnamara commented on GitHub (Jun 24, 2016):
@silvioprog
Thanks for the howto. I'll update the docs once I do a bit more testing.
And speaking of testing I also need to make some of these changes to the test suite. I am also seeing a unit test failure in MinGW but not in any of the other environments so I need to look at that.
@Alexhuszagh If you could check for any build issues in Msys2 and your other environments that would be great too.
@Alexhuszagh commented on GitHub (Jun 24, 2016):
@jmcnamara, There are no more compiler warnings with Msys2 or Cygwin. With MinGW64, it also compiles, however, there were a lot of warnings. (Included below).
Thank you so much.
MinGW Warnings:
@silvioprog commented on GitHub (Jun 24, 2016):
Hello @Alexhuszagh, he already fixed this warnings, and now you don't need to use
CC, just callmakewithout params. Take a look at my new install script at last message: https://github.com/jmcnamara/libxlsxwriter/issues/53#issuecomment-228228434.@Alexhuszagh commented on GitHub (Jun 24, 2016):
@silvioprog MinGW64 for good reasons is not part of my path on Windows, so yes, I do actually have to call
CC=/path/to/mingw. But it's not really relevant. The position-independent code is already position independent, so the -fPIC flag is redundant, and that's 90% of the warnings (and also not really relevant). Also, that's cloned from the latest source.The last is likely because mingw64 reverts to an old C version, which does not support a specific type he defined. Passing -std=gnu11 would likely fix that.
@silvioprog commented on GitHub (Jun 24, 2016):
Hm... strange, I don't have
mingwin my Windows path, I just use themingw32_shell.batin a MinGW installation via this steps from scratch, using the default MinGW environment. :-/ And it compiles xlsxwriter without any warning:I took a look at last commits and it seems jmcnamara removed the -fPIC for MinGW env:
be0097b717 (diff-f57f2991a6aa25fe45d8036c51bf8b4dR48). Sorry if these informations are wrong, I think @jmcnamara can explain this problem, because I can't see any warning compiling xlsxwriter in a fresh MinGW installation. ^^'My Windows path:
@Alexhuszagh commented on GitHub (Jun 24, 2016):
@silvioprog MinGW and MSys and completely different code bases than MinGW64 and MSys2. The latter were created as an independent re-write to support 64-bit architecture. It's also possible, overall, I'm just glad it compiles on all the Windows build systems I've tried now, which includes Cygwin DLL, Cygwin, MSys2, MinGW64, and others have reported MinGW, and Visual Studio working. Seems like Windows compatibility issues are over for this commit.
@silvioprog commented on GitHub (Jun 24, 2016):
Good news buddy! And thanks sharing these informations, I'm very begginer in C/make, so useful tips are welcome. :-)
I think this issue is now solved, so I'm closing it, but feel free to reopen if necessary.
ps. @jmcnamara just ctrl+f + "mingw" at getting_started and can't see any mingw entry, do you commited that?
@jmcnamara commented on GitHub (Jun 25, 2016):
@silvioprog I'm still testing this and I haven't got to the documentation yet so I'm going to reopen this issue until it is ready for a release. Excuse the spam. :-)
@jmcnamara commented on GitHub (Jun 25, 2016):
@Alexhuszagh I've added support for Msys2 to the makefiles if you get chance to retest.
Also, could you give me some more details on how to reproduce the case with warnings.
If the build system detects the environment correctly then there shouldn't be any of those warnings.
Also @silvioprog and @Alexhuszagh the test system should be working now. As a minimum you should be able to run the unit tests since they don't have any external dependencies:
You can also run the functional tests (which compare against actual excel files) if you install python and pytest (which will require easy_install or pip). With those installed you can run:
Or
The
V=1is a makefile verbose option to show what is happening since the test compilations can be slow.Also, I'm not going to support base mingw/msys since the unit tests fail for (what I think is) an invalid error, because it doesn't have a native python for testing and because it doesn't seem to be under active development. I will support mingw-w64/msys2 and cygwin.
Final note, I haven't got around to 32 bit testing yet.
Thanks to both of you for your help.
@Alexhuszagh commented on GitHub (Jun 25, 2016):
@silvioprog Actually I think I know the issue. I use Cmder as my default terminal, which is a Windows terminal, but accepts shell commands and has
/bin/shin the path (confusing right, but it's amazing), so the warnings may be since it detects a Cygwin-like environment but is actually just a standard command prompt. It may have nothing to do with MinGW64 and MinGW32. I'll re-run it from both Cmder and the standard Command Prompt.And @jmcnamara, your XlsxWriter (the Python program) helped me a lot, and this package is now helping me once again, so I'm glad to help out in any way.
@Alexhuszagh commented on GitHub (Jun 25, 2016):
@jmcnamara I'll post the error tracebacks I get for each build separately, starting with Msys2. Apparently there is something wrong with the string-based tests in the in the Msys2 build.
(For make test_unit V=1)
@Alexhuszagh commented on GitHub (Jun 25, 2016):
Cygwin (DLL-based) compiles fine and all tests pass.
@Alexhuszagh commented on GitHub (Jun 25, 2016):
MinGW64 fails identically to Msys2. I might take a look and see what's going on, it's probably a single failure point since it seems to be every string-based test returns a null string, and the rest work.
@Alexhuszagh commented on GitHub (Jun 25, 2016):
And just as a confirmation, everything builds on Linux.
@jmcnamara commented on GitHub (Jun 25, 2016):
@Alexhuszagh
Yes, sounds cool. :-)
That is probably the issue. The Makefile does a
unameand changes some of the build parameters. So it expects some sort of environment like Msys2 or Cygwin in addition to the toolchain. You could edit the Makefile and addMING_LIKE = ynear the top. If this was Linux you could do the following but I don't know if that will work in the Windows Cmd shell:I get a clean build and all passing tests on a fresh Msys2 + Mingw-w64 install. If they tests are failing like that then there is something fundamental broken. Could you give some more details on the env that it is failing in.
P.S. It is okay to cut long tracebacks and logs down to just the first few repeated failures. :-) I've done that in the Github thread.
Does this mean Cmd + Mingw-w64?
Yes. I have a Travis-CI test setup that compiles every commit with gcc and clang on Linux. It also runs valgrind on all the tests and examples to make sure there aren't any memory leaks. I also have a local Linux VM where I test with some other non mainstream compilers. My development environment is OS X with clang so that is tested as well.
@jmcnamara commented on GitHub (Jun 25, 2016):
Actually maybe the following will work:
@jmcnamara commented on GitHub (Jun 25, 2016):
Just tested with MSYS and Mingw-w32 and there are some test failures. However, I can fix them.
In the meantime for anyone playing along at home here is how I am setting up MSYS (which I hadn't used before and which is very nice):
@jmcnamara commented on GitHub (Jun 25, 2016):
I've pushed a fix for the 32bit issue. I now have passing tests in 4 Windows envs:
I think this is close to completion. I need to figure out if I can add a 32 bit build and test to the Travis CI and then add the docs.
Update: I've added 32bit builds for gcc and clang to the Travis-CI test matrix: https://travis-ci.org/jmcnamara/libxlsxwriter/builds/140301011
@Alexhuszagh commented on GitHub (Jun 27, 2016):
@jmcnamara 245 tests still fail with the 64 bit (MSYS2, not MSYS) version of MSYS. The functional tests fail as well.
@jmcnamara commented on GitHub (Jun 27, 2016):
@Alexhuszagh I see all tests passing in clean installs of MSYS2 64 and 32 bit. I've also uninstalled and installed several times to check.
Can you give more details on your installation or better still test in a new installation as follows:
@jmcnamara commented on GitHub (Jun 28, 2016):
@Alexhuszagh I think I may know what is causing the issue that you are seeing. The libxlsxwriter library uses
tempfile()to create temporary filehandle in the test code and also to create temp file for files for the xlsx xml data.If your Windows temp directory isn't writeable/accessible then you will get test failures like the ones you are seeing. This probably shouldn't be the case inside MSYS2 but it may occur if you are running inside the CMD shell.
Can you compile and run one of the example programs. They generate warnings about unwritable directories/files:
@jmcnamara commented on GitHub (Jul 3, 2016):
I've add documentation for MinGW support and pushed it to a new release: http://libxlsxwriter.github.io/getting_started.html#gsg_ming
One final thanks for your input. Closing.
@Alexhuszagh commented on GitHub (Jul 6, 2016):
Hi sorry,
Other obligations got in the way. By any chance, @jmcnamara I made the examples in the examples directory and was getting a tempfile error, which I then looked in your source code for examples:
"@note The libxlsxwriter library uses files in the system TEMP directory during
assembly of a xlsx file. On Windows this directory may not be writeable by a
libxlsxwriter application. To work around this you can make the Windows TEMP
directory writeable or if you are using MSYS/MSYS2 you can change the
/tmpdirectory using the system fstab file. Or alternatively you can define your
own TEMP directory in libxlsxwriter using the
USE_TMPFILE2workaround insrc/utility.c"So I actually looked at the source, and I found this:
Where tmpfile() comes from <stdio.h>, it employs tmpnam or the same underlying algorithm to get a unique name, and unfortunately, for some weird reason, tmpnam does not work (at all) on my install. This is complicated, but basically comes down to the following re-definition:
So, it uses the current tmp directory as the source directory, and weirdly also append a trailing '', treating the temporary name as a temporary directory.
A cross-platform solution that works for Windows would be the following:
Once I fix that, the examples start working. That code is given to you, if you wish to use it (it was inspired from here).
@Alexhuszagh commented on GitHub (Jul 6, 2016):
Ok, I also tried most of the examples and only constant_memory.c failed, due to an XML corruption error.
All the chart, panes, images, merged ranges, chart styles, tab colors, tutorials, etc. worked. Overall, it seems like there's an issue with the testing framework on my end (could it have to do with wchar vs. char differences?), since 245 of 267 tests fail, but the code works in production.
@jmcnamara commented on GitHub (Jul 6, 2016):
@Alexhuszagh Thanks for the detailed breakdown.
Did you try the alternative
lxw_tmpfile()implementation in utility.c that is under theUSE_TMPFILE2define: https://github.com/jmcnamara/libxlsxwriter/blob/master/src/utility.c#L488You will need to change the
/tmp/in the following to some writeable dir. Possibly with a Windows path like"C:\\MyPath\\Temp\\":@Alexhuszagh commented on GitHub (Jul 6, 2016):
@jmcnamara I did not, but that implementation should only work reproducibly on *Nix systems or *Nix like systems (it would work within a MSYS environment, but not with the compiled program outside such an environment, since the /tmp directory does not exist on Windows). Also, the Windows temp directory is well structured, typically
C:\\Users\\$USER\\AppData\\Local\\Temp, and can be accessed with theTMPorTEMPenvironment variables. On *Nix systems this isTMPDIR, which is how Qt does it.An example in pseudocode looks like this:
I also understand you're not worried about race conditions or the like, so my implementation may be somewhat overkill, but it should produce a fully random character string. However, at least for the directory, this would be useful, since it is better than the standard library tools (tmpnam isn't great, tmpfile uses the same underlying algorithm, and mkstemp only exists for POSIX compliant systems).
@jmcnamara commented on GitHub (Jul 6, 2016):
Can you try it. I've had a report from a MinGW user that it worked from them.
I guess I wasn't clear on that. You need to change the path to a writeable dir on your system.
@jmcnamara commented on GitHub (Jul 10, 2016):
@Alexhuszagh I got a similar report from a user on Windows using MSVC: #63
I ended up using the tmpfileplus library you linked to above to fix the issue so your issue is probably resolved as well. If not add a comment to #63.