github-starred/libxlsxwriter

Fork 0

mirror of https://github.com/jmcnamara/libxlsxwriter.git synced 2026-05-15 14:15:54 -06:00

[GH-ISSUE #108] Missing iowin32.c in CMakeList.txt #88

New issue

Closed

opened 2026-05-05 11:38:31 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 11:38:31 -06:00

Owner

Originally created by @ragundo on GitHub (Jul 7, 2017).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/108

Originally assigned to: @jmcnamara on GitHub.

Hi
After two hours trying to figure out why I was always getting linker error after compiling a VS2015 solution of the libreary using the new cmake feature, I realized that iowin32.c is not added to the library with the provided CMakeLists.txt

Original CMakeLists.txt
list(APPEND LXW_SOURCES third_party/minizip/ioapi.c third_party/minizip/zip.c)

Modified
list(APPEND LXW_SOURCES third_party/minizip/ioapi.c third_party/minizip/zip.c third_party/minizip/iowin32.c)

After changing this, it compiles ok , with all the examples and libxlsxwriter generates excel files.
Now my problem is that the generated file doesn't respect the name provided in the code:

lxw_workbook *workbook = workbook_new("anatomy.xlsx");

but only the first letter is written (no extension `etc)```

Originally created by @ragundo on GitHub (Jul 7, 2017). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/108 Originally assigned to: @jmcnamara on GitHub. Hi After two hours trying to figure out why I was always getting linker error after compiling a VS2015 solution of the libreary using the new cmake feature, I realized that `iowin32.c` is not added to the library with the provided CMakeLists.txt **Original CMakeLists.txt** `list(APPEND LXW_SOURCES third_party/minizip/ioapi.c third_party/minizip/zip.c)` **Modified** `list(APPEND LXW_SOURCES third_party/minizip/ioapi.c third_party/minizip/zip.c third_party/minizip/iowin32.c)` After changing this, it compiles ok , with all the examples and libxlsxwriter generates excel files. Now my problem is that the generated file doesn't respect the name provided in the code: `lxw_workbook *workbook = workbook_new("anatomy.xlsx");` but only the first letter is written (no extension `etc)```

gitea-mirror

2026-05-05 11:38:31 -06:00

closed this issue
added the
question
label

gitea-mirror commented

2026-05-05 11:38:37 -06:00

Author

Owner

@jmcnamara commented on GitHub (Jul 10, 2017):

Hi @ragundo,

Could you post the steps you did so that I can try to reproduce this.

Now my problem is that the generated file doesn't respect the name provided in the code:

That is a know issue with MSVC/libxlsxwriter which is usually fixed by the following function which should be included for MSVC when _WIN32 is defined:

https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L43

Check the code in MSVC to see if it is defined in or out.

@Alexhuszagh, can you have a look at the CMake issue.

@jmcnamara commented on GitHub (Jul 10, 2017): Hi @ragundo, Could you post the steps you did so that I can try to reproduce this. > Now my problem is that the generated file doesn't respect the name provided in the code: That is a know issue with MSVC/libxlsxwriter which is usually fixed by the following function which should be included for MSVC when `_WIN32` is defined: https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L43 Check the code in MSVC to see if it is defined in or out. @Alexhuszagh, can you have a look at the CMake issue.

gitea-mirror commented

2026-05-05 11:38:39 -06:00

Author

Owner

@Alexhuszagh commented on GitHub (Jul 10, 2017):

Hi @jmcnamara, I think I've found the issue with this. I've found two small issues with the CMakeLists, I'll send a patch later today. One is the OP's issue, the other is setting _WIN32 for CMake legacy.

@Alexhuszagh commented on GitHub (Jul 10, 2017): Hi @jmcnamara, I think I've found the issue with this. I've found two small issues with the CMakeLists, I'll send a patch later today. One is the OP's issue, the other is setting _WIN32 for CMake legacy.

gitea-mirror commented

2026-05-05 11:38:41 -06:00

Author

Owner

@Alexhuszagh commented on GitHub (Jul 10, 2017):

@jmcnamara, if you would like, I can add in a CI file for AppVeyor, which provides continual integration using Visual Studio, in addition to Travis CI, so these VS-specific issues won't occur again.

@Alexhuszagh commented on GitHub (Jul 10, 2017): @jmcnamara, if you would like, I can add in a CI file for AppVeyor, which provides continual integration using Visual Studio, in addition to Travis CI, so these VS-specific issues won't occur again.

gitea-mirror commented

2026-05-05 11:38:43 -06:00

Author

Owner

@jmcnamara commented on GitHub (Jul 10, 2017):

if you would like, I can add in a CI file for AppVeyor, which provides continual integration using Visual Studio, in addition to Travis CI, so these VS-specific issues won't occur again.

That sounds like a good idea.

@jmcnamara commented on GitHub (Jul 10, 2017): > if you would like, I can add in a CI file for AppVeyor, which provides continual integration using Visual Studio, in addition to Travis CI, so these VS-specific issues won't occur again. That sounds like a good idea.

gitea-mirror commented

2026-05-05 11:38:45 -06:00

Author

Owner

@jmcnamara commented on GitHub (Jul 10, 2017):

@Alexhuszagh P.S. I've set up a AppVeyor project (but haven't configured the build .yml yet): https://ci.appveyor.com/project/jmcnamara/libxlsxwriter

@jmcnamara commented on GitHub (Jul 10, 2017): @Alexhuszagh P.S. I've set up a AppVeyor project (but haven't configured the build .yml yet): https://ci.appveyor.com/project/jmcnamara/libxlsxwriter

gitea-mirror commented

2026-05-05 11:38:46 -06:00

Author

Owner

@Alexhuszagh commented on GitHub (Jul 10, 2017):

@jmcnamara I've patched that bug, and set up upstream continual integration on Tea-CI (MSYS2/MinGW, it's what the MSYS2 project uses), AppVeyor (MSVC), and I should have everything working. I've had a slight issue with the MSVC builds, so I'll patch that, make everything nice and pretty in the commit history, and submit a pull request. Let me know if you want Tea-CI, or do not. I have one for my upstream fork, but I can gladly remove it.

@Alexhuszagh commented on GitHub (Jul 10, 2017): @jmcnamara I've patched that bug, and set up upstream continual integration on Tea-CI (MSYS2/MinGW, it's what the MSYS2 project uses), AppVeyor (MSVC), and I should have everything working. I've had a slight issue with the MSVC builds, so I'll patch that, make everything nice and pretty in the commit history, and submit a pull request. Let me know if you want [Tea-CI](https://tea-ci.org/), or do not. I have one for my upstream fork, but I can gladly remove it.

gitea-mirror commented

2026-05-05 11:38:48 -06:00

Author

Owner

@jmcnamara commented on GitHub (Jul 11, 2017):

@ragundo Can you check that your issue is resolved on master.

@jmcnamara commented on GitHub (Jul 11, 2017): @ragundo Can you check that your issue is resolved on master.