Code Monkey home page Code Monkey logo

Comments (51)

jmcnamara avatar jmcnamara commented on July 17, 2024

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 _WIN32 define.

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

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

According to the following it looks like MinGW does define _WIN32: http://stackoverflow.com/questions/9025708/mingw-not-defining-win32-error-in-preprocessor-directives

Whether that is valid or not I don't know. Try changing this code in packager.c

    /* Create a zip container for the xlsx file. */
#ifdef _WIN32
    packager->zipfile = _open_zipfile_win32(packager->filename);
#else
    packager->zipfile = zipOpen(packager->filename, 0);
#endif

To just:

    /* Create a zip container for the xlsx file. */
    packager->zipfile = zipOpen(packager->filename, 0);

There is one other section of code in a _WIN32 define in the same file that you can remove if necessary.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

Hello @jmcnamara

So, I can use cygwin, do you have some doc showing the steps to build on that?

The libxlsxwriter is a very useful library, it should provide compiled binaries (.dll) for Windows and tar.gz for Linux.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

I got some progress with cygwin. Now the error is related to ioapi:

$ cd libxlsxwriter-RELEASE_0.3.8/
$ make
make[1]: Entering directory '/home/silvioprog/libxlsxwriter-RELEASE_0.3.8/third_party/minizip'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/silvioprog/libxlsxwriter-RELEASE_0.3.8/third_party/minizip'
make[1]: Entering directory '/home/silvioprog/libxlsxwriter-RELEASE_0.3.8/src'
../third_party/minizip/ioapi.so:ioapi.c:(.text+0x196): undefined reference to `fseeko64'
../third_party/minizip/ioapi.so:ioapi.c:(.text+0x1db): undefined reference to `ftello64'
../third_party/minizip/ioapi.so:ioapi.c:(.text+0x218): undefined reference to `fopen64'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:67: libxlsxwriter.so] Error 1
make[1]: Leaving directory '/home/silvioprog/libxlsxwriter-RELEASE_0.3.8/src'
make: *** [Makefile:19: all] Error 2

I tried it too:

$ make CFLAGS='-lminizip'

Got same error. I'm not sure what library I need to link ...

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

Hm... it seems make generates .so intead of .dll:

$ make -C third_party/minizip
$ ls third_party/minizip/ | grep '^zip.'
zip.c
zip.h
zip.o
zip.so << Why?

I want to build on Windows just do get the libxlsxwriter.dll. :-/

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

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 .a file is and the example programs compile and run within cygwin.

$ git diff
diff --git a/src/Makefile b/src/Makefile
index 2f0ede7..ff71f05 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -19,11 +19,11 @@ INC_DIR     = ../include
 MINIZIP_DIR = ../third_party/minizip

 # Flags passed to compiler.
-CFLAGS   += -g -O3 -Wall -Wextra -pedantic -ansi
+CFLAGS   += -g -O3 -Wall -Wextra -pedantic -ansi -Wno-char-subscripts

 # Library names.
 LIBXLSXWRITER_A  = libxlsxwriter.a
-LIBXLSXWRITER_SO = libxlsxwriter.so
+LIBXLSXWRITER_SO = libxlsxwriter.dll

 # Library with additional non-static functions for testing.
 LIBXLSXWRITER_TO = libxlsxwriter_test.a
@@ -32,13 +32,13 @@ LIBXLSXWRITER_TO = libxlsxwriter_test.a
 ARFLAGS = rc

 # Flags passed to dynamic linker.
-SOFLAGS = -shared -fPIC
+SOFLAGS = -shared

 # Change shared lib options on OS X.
 UNAME := $(shell uname)
 ifeq ($(UNAME), Darwin)
 LIBXLSXWRITER_SO = libxlsxwriter.dylib
-SOFLAGS = -dynamiclib -fPIC -install_name /usr/lib/$(LIBXLSXWRITER_SO)
+SOFLAGS = -dynamiclib -install_name /usr/lib/$(LIBXLSXWRITER_SO)
 endif


@@ -78,7 +78,7 @@ test_compile : $(OBJS)
        $(Q)$(CC)       -I$(INC_DIR) $(CFLAGS) $(CXXFLAGS) -c $<

 %.so : %.c $(HDRS)
-       $(Q)$(CC) -fPIC -I$(INC_DIR) $(CFLAGS) $(CXXFLAGS) -c $< -o $@
+       $(Q)$(CC)       -I$(INC_DIR) $(CFLAGS) $(CXXFLAGS) -c $< -o $@

 %.to : %.c $(HDRS)
        $(Q)$(CC) -g -O0 -DTESTING -I$(INC_DIR) $(CFLAGS) $(CXXFLAGS) -c $< -o $@
diff --git a/third_party/minizip/Makefile b/third_party/minizip/Makefile
index 90881f2..9034a86 100644
--- a/third_party/minizip/Makefile
+++ b/third_party/minizip/Makefile
@@ -9,7 +9,7 @@ ifdef V
 Q=
 endif

-CFLAGS = -O3 -DNOCRYPT -DNOUNCRYPT
+CFLAGS = -O3 -DNOCRYPT -DNOUNCRYPT  -DUSE_FILE32API

 all: ioapi.o zip.o  ioapi.so zip.so

@@ -17,7 +17,7 @@ all: ioapi.o zip.o  ioapi.so zip.so
        $(Q)$(CC)       -c $(CFLAGS) $<

 %.so : %.c
-       $(Q)$(CC) -fPIC -c $(CFLAGS) $< -o $@
+       $(Q)$(CC)       -c $(CFLAGS) $< -o $@

 clean:
        $(Q)/bin/rm -f *.o *.so

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

I'm going to try it on cygwin and mingw too ...

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

I forgot to ask about 32 bits... can I generate a 32bis libxlsxwriter.dll?

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

can I generate a 32bis libxlsxwriter.dll?

I haven't done it but it should be possible.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

Bro, I have bad news. :-( It fails in:

  • mingw-w64 - 32/64 bits > same error, even after some changes in the Makefile.
  • cygwin - 32/64 bits > same above.

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". :-)

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

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:

gcc -dM -E - < /dev/null | grep MINGW
#define __MINGW32__ 1
#define __MINGW64__ 1

I was able to fix packager.c with two preprocessor directives, both identical, as follows:

#if defined(_WIN32) && !defined(__MINGW32__)

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.

$ file /mingw64/lib/libxlsxwriter.so
/mingw64/lib/libxlsxwriter.so: PE32+ executable (DLL) (console) x86-64, for MS Windows

I might look at packager.c to see if I can fix this.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

Quick confirmation that a program linked to the patched file compiles, links and executes fine on my system.

Thanks for the excellent library jmcnamara.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

@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! :-)

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

I agree @Alexhuszagh . The libxlsxwriter is awesome, I want to share it in many places like social network, programming groups/forums, university, work etc. :-)

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@Alexhuszagh thanks. I'm working on some fixes for the mingw and cygwn issues.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

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.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

YYYEEESSS!!! \o/

@jmcnamara you fixed the problem! I saw the latest commit (be0097b), so after update my repo and rebuild the library, finally I got the libxlsxwriter.dll about 750KB, but after strip it only 214KB. I can send a patch to declare the make option install-strip.

Now, the only command is:

$ make CC=gcc install-strip

And the magic happens! :-)

Two observations:

  • on MinGW, the makefile should be changed to choose (or find) the gcc instead of cc;
  • the library compiles fine, but with many warnings (see the log at bottom).

All my steps to build the library from scratch (we should update the documentation showing the steps to build xlsxwriter on MinGW, because it can be very useful for begginers.):

:: Get and install MinGW-w64: http://downloads.sourceforge.net/project/msys2/Base/i686/msys2-i686-20150916.exe

:: Open the Command Prompt and:
cd C:\msys32 & mingw32_shell.bat

:: Installing tools:
pacman -S mingw-w64-i686-gcc make wget unzip

:: Downloading and upacking xlsxwriter ...
cd ~ && wget -c https://github.com/jmcnamara/libxlsxwriter/archive/master.zip && unzip master.zip && cd libxlsxwriter-master

:: Building and intalling xlsxwriter:
make CC=gcc && strip lib/libxlsxwriter.dll && strip lib/libxlsxwriter.a && make install

:: Finally, get compiled shared library at "C:\msys32\usr\lib\libxlsxwriter.dll" and enjoy it! :-)

The make log:

make[1]: Entering directory '/home/silvioprog/libxlsxwriter-master/third_party/minizip'
ioapi.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /* ioapi.h -- IO base function header for compress/uncompress .zip
 ^
zip.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /* zip.c -- IO on .zip files using zlib
 ^
make[1]: Leaving directory '/home/silvioprog/libxlsxwriter-master/third_party/minizip'
make[1]: Entering directory '/home/silvioprog/libxlsxwriter-master/src'
In file included from ../include/xlsxwriter/xmlwriter.h:25:0,
                 from workbook.c:10:
workbook.c: In function 'workbook_add_worksheet':
workbook.c:1418:26: warning: ISO C90 does not support '__func__' predefined identifier [-Wpedantic]
                          __func__, init_data.name);
                          ^
../include/xlsxwriter/common.h:200:49: note: in definition of macro 'LXW_WARN_FORMAT2'
     fprintf(stderr, "[WARNING]: " message "\n", var1, var2)
                                                 ^
workbook.c: In function 'workbook_set_custom_property_string':
workbook.c:1668:67: warning: ISO C90 does not support '__func__' predefined identifier [-Wpedantic]
         LXW_WARN_FORMAT("%s(): parameter 'name' cannot be NULL.", __func__);
...
make[1]: Leaving directory '/home/silvioprog/libxlsxwriter-master/src'

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

@jmcnamara oops, I just see your message now! ^^'

I'm going to re-update and re-build it now ... :-D

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

@jmcnamara I did some changes in the makefiles that chooses the gcc compiler and declares the install-strip and uninstall options, can you check this attached patch? If so, feel free to change it, because I'm not sure if the gcc can 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

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

I fixed the warnings and the CC issue.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

I also added uninstall and strip makefile targets but not install-strip since not everyone will want to install stripped versions of the binaries and it can be made up from the other 2.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

In only one word: P.E.R.F.E.C.T!

Now, we just:

:: Get and install MinGW-w64: http://downloads.sourceforge.net/project/msys2/Base/i686/msys2-i686-20150916.exe

:: Open the Windows Command Prompt and:
cd C:\msys32 & mingw32_shell.bat

:: Installing tools:
pacman -S mingw-w64-i686-gcc make wget unzip

:: Downloading and upacking xlsxwriter ...
cd ~ && wget -c https://github.com/jmcnamara/libxlsxwriter/archive/master.zip && unzip master.zip && cd libxlsxwriter-master

:: Building and intalling xlsxwriter:
make && make strip && make install

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.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

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.

@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.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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:

λ make CC=C:\mingw64\bin\gcc.exe
make[1]: Entering directory 'C:/dev/libxlsxwriter/third_party/minizip'
ioapi.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /* ioapi.h -- IO base function header for compress/uncompress .zip
 ^
zip.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /* zip.c -- IO on .zip files using zlib
 ^
make[1]: Leaving directory 'C:/dev/libxlsxwriter/third_party/minizip'
make[1]: Entering directory 'C:/dev/libxlsxwriter/src'
In file included from ../include/xlsxwriter/third_party/minizip/zip.h:59:0,
                 from ../include/xlsxwriter/packager.h:13,
                 from packager.c:11:
../include/xlsxwriter/third_party/minizip/ioapi.h:106:23: warning: ISO C90 does not support 'long long' [-Wlong-long]
 typedef unsigned long long int ZPOS64_T;
                       ^
In file included from ../include/xlsxwriter/third_party/minizip/zip.h:59:0,
                 from ../include/xlsxwriter/packager.h:13,
                 from workbook.c:13:
../include/xlsxwriter/third_party/minizip/ioapi.h:106:23: warning: ISO C90 does not support 'long long' [-Wlong-long]
 typedef unsigned long long int ZPOS64_T;
                       ^
packager.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
In file included from ../include/xlsxwriter/third_party/minizip/zip.h:59:0,
                 from ../include/xlsxwriter/packager.h:13,
                 from packager.c:11:
../include/xlsxwriter/third_party/minizip/ioapi.h:106:23: warning: ISO C90 does not support 'long long' [-Wlong-long]
 typedef unsigned long long int ZPOS64_T;
                       ^
hash_table.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
custom.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
app.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
styles.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
utility.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
workbook.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
In file included from ../include/xlsxwriter/third_party/minizip/zip.h:59:0,
                 from ../include/xlsxwriter/packager.h:13,
                 from workbook.c:13:
../include/xlsxwriter/third_party/minizip/ioapi.h:106:23: warning: ISO C90 does not support 'long long' [-Wlong-long]
 typedef unsigned long long int ZPOS64_T;
                       ^
chart.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
core.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
xmlwriter.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
relationships.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
worksheet.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
shared_strings.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
content_types.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
theme.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
format.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
drawing.c:1:0: warning: -fPIC ignored for target (all code is position independent)
 /*****************************************************************************
 ^
make[1]: Leaving directory 'C:/dev/libxlsxwriter/src'

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

Hello @Alexhuszagh, he already fixed this warnings, and now you don't need to use CC, just call make without params. Take a look at my new install script at last message: #53 (comment).

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

Hm... strange, I don't have mingw in my Windows path, I just use the mingw32_shell.bat in a MinGW installation via this steps from scratch, using the default MinGW environment. :-/ And it compiles xlsxwriter without any warning:

$ make
make[1]: Entering directory '/home/silvioprog/libxlsxwriter-master/third_party/minizip'
make[1]: Leaving directory '/home/silvioprog/libxlsxwriter-master/third_party/minizip'
make[1]: Entering directory '/home/silvioprog/libxlsxwriter-master/src'
make[1]: Leaving directory '/home/silvioprog/libxlsxwriter-master/src'
$ ls lib
libxlsxwriter.a  libxlsxwriter.dll

I took a look at last commits and it seems jmcnamara removed the -fPIC for MinGW env: be0097b#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:

C:\Users\silvi>echo %PATH%
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\cURL\bin;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\Program Files\Git\cmd;C:\Program Files\TortoiseGit\bin;C:\Users\Public\Documents\Embarcadero\Studio\18.0\Bpl;C:\Users\Public\Documents\Embarcadero\Studio\18.0\Bpl\Win64;C:\Users\Public\Documents\Embarcadero\Studio\18.0\Bpl

C:\Users\silvi>cc
'cc' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\silvi>gcc
'gcc' is not recognized as an internal or external command,
operable program or batch file.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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.

from libxlsxwriter.

silvioprog avatar silvioprog commented on July 17, 2024

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?

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@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. :-)

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@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:

make test_unit V=1

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:

make test_functional V=1

Or

make test V=1

The V=1 is 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.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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/sh in 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.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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)

TEST 1/267 utility:lxw_rowcol_to_range [OK]
TEST 2/267 utility:lxw_rowcol_to_range_abs [OK]
TEST 3/267 utility:lxw_quote_sheetname [OK]
TEST 4/267 utility:lxw_col_to_name [OK]
TEST 5/267 utility:lxw_name_to_row [OK]
TEST 6/267 utility:lxw_rowcol_to_cell [OK]
TEST 7/267 utility:lxw_rowcol_to_cell_abs [OK]
TEST 8/267 utility:lxw_rowcol_to_formula_abs [OK]
TEST 9/267 utility:_datetime_date_and_time [OK]
TEST 10/267 utility:_datetime_date_only [OK]
TEST 11/267 utility:_datetime_date_only_1904 [OK]
TEST 12/267 utility:_datetime_time_only [OK]
TEST 13/267 utility:lxw_name_to_col [OK]
TEST 14/267 utility:lxw_name_to_col_2 [OK]
TEST 15/267 utility:lxw_strerror [OK]
TEST 16/267 xmlwriter:xml_declaration [FAIL]
  ERR: test_xmlwriter.c:22
        expected '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
',
        got      ''
TEST 17/267 xmlwriter:xml_start_tag [FAIL]
  ERR: test_xmlwriter.c:34
        expected '<foo>',
        got      ''
TEST 18/267 xmlwriter:xml_start_tag_with_attributes [FAIL]
  ERR: test_xmlwriter.c:52
        expected '<foo span="8" baz="7">',
        got      ''
TEST 19/267 xmlwriter:xml_start_tag_with_attributes_to_escape [FAIL]
  ERR: test_xmlwriter.c:71
        expected '<foo span="&amp;&lt;&gt;&quot;">',
        got      ''
...
.. Snip
...
RESULTS: 267 tests (22 ok, 245 failed, 0 skipped) ran in 69 ms
make[1]: *** [Makefile:97: test] Error 245
make[1]: Leaving directory '/home/Alex Huszagh/libxlsxwriter/test/unit'
make: *** [Makefile:50: test_unit] Error 2

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

Cygwin (DLL-based) compiles fine and all tests pass.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

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.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

And just as a confirmation, everything builds on Linux.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@Alexhuszagh

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/sh in the path (confusing right, but it's amazing),

Yes, sounds cool. :-)

That is probably the issue. The Makefile does a uname and 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 add MING_LIKE = y near 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:

MING_LIKE=1 make

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.

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.

MinGW64 fails identically to Msys2.

Does this mean Cmd + Mingw-w64?

And just as a confirmation, everything builds on Linux.

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.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

You could edit the Makefile and add MING_LIKE = y near 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:

MING_LIKE=1 make

Actually maybe the following will work:

make MING_LIKE=1

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

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):

# Install MSYS2 32 or 64 bit from http://msys2.github.io/

# Start msys shell.

# Update pacman according to the msys docs.
pacman -Sy pacman
pacman -Syu

# Restart shell and continue upgrade
pacman -Su

# Install the dev tools for libxlsxwriter.
pacman -S git gcc make zlib-devel

# Clone and build libxlsxwriter.
git clone https://github.com/jmcnamara/libxlsxwriter.git
cd libxlsxwriter/
make V=1

# Run the unit tests.
make test_unit V=1

# Install the Python dependencies for the functional tests.
pacman -S python
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
rm get-pip.py
pip install pytest

# Run the functional tests.
make test_functional V=1

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

I've pushed a fix for the 32bit issue. I now have passing tests in 4 Windows envs:

  • Cygwin: Compiles and unit and functional tests pass
  • Msys2 + Mingw64: Compiles and unit and functional tests pass
  • Msys2 + Mingw32: Compiles and unit and functional tests pass
  • Msys + Mingw: Compiles and unit tests pass (with compilation warnings from the test library)

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

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@jmcnamara 245 tests still fail with the 64 bit (MSYS2, not MSYS) version of MSYS. The functional tests fail as well.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@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:

# Install MSYS2 32 or 64 bit from http://msys2.github.io/

# Install the dev tools for libxlsxwriter.
pacman -S git gcc make zlib-devel

# Clone and build libxlsxwriter.
git clone https://github.com/jmcnamara/libxlsxwriter.git
cd libxlsxwriter/
make V=1

# Run the unit tests.
make test_unit V=1

# Install the Python dependencies for the functional tests.
pacman -S python
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
rm get-pip.py
pip install pytest

# Run the functional tests.
make test_functional V=1

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@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:

make examples
./examples/hello

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

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.

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

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 /tmp
directory using the system fstab file. Or alternatively you can define your
own TEMP directory in libxlsxwriter using the USE_TMPFILE2 workaround in
src/utility.c"

So I actually looked at the source, and I found this:

/*
 * Thin wrapper for tmpfile() so it can be over-ridden with a safer version if
 * required.
 */
#ifndef USE_TMPFILE2
FILE *
lxw_tmpfile(void)
{
    return tmpfile();
}

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:

/*
 * Tmpnam, tmpfile and, sometimes, _tempnam try to create
 * temp files in the root directory of the current drive
 * (not in pwd, as suggested by some older MS doc's).
 * Redefining these macros does not effect the CRT functions.
 */
#define _P_tmpdir   "\\"
#ifndef __STRICT_ANSI__
#define P_tmpdir _P_tmpdir
#endif
#define _wP_tmpdir  L"\\"

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:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>


#define CHARS "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
#define NCHARS (sizeof(CHARS) - 1)
#define FILELENGTH 10

#ifdef _WIN32
#define SEPARATOR '\\'
#else
#define SEPARATOR '/'
#endif


// Fairly strong, pseudorandom generator for valid file identifiers
void randomize(char *s)
{
  unsigned int r;
  srand(time(NULL));
  for (unsigned int i = 0; i < FILELENGTH; ++i)
  {
    r = rand() % NCHARS;
    s[i] = (CHARS)[r];
  }
}


// Generate temporary function name
static char * tempname()
{
    // get our drive
    char *drive = getenv("TMP");
    if (!drive) {
        drive = getenv("TEMP");
    }
    // create our randomized basename
    char basename[FILELENGTH+1];
    randomize(basename);
    basename[FILELENGTH] = '\0';

    // move everything into the full path
    unsigned int drivelen = strlen(drive);
    char *path = malloc(drivelen+FILELENGTH+2);
    memmove(&path[0], drive, drivelen);
    path[drivelen] = SEPARATOR;
    memmove(&path[drivelen+1], basename, FILELENGTH+1);

    return path;
}


int main()
{
    // This highlights the buggy behavior
    char *path = tmpnam(NULL);
    printf("Path to temp directory: %s\n", path);

    // This highlights the fixed behavior
    char *temp = tempname();
    printf("New path to temp directory, %s\n", temp);
    free(temp);

    return 0;
}

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).

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

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.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@Alexhuszagh Thanks for the detailed breakdown.

A cross-platform solution that works for Windows would be the following:

Did you try the alternative lxw_tmpfile() implementation in utility.c that is under the USE_TMPFILE2 define: https://github.com/jmcnamara/libxlsxwriter/blob/master/src/utility.c#L488

You will need to change the /tmp/ in the following to some writeable dir. Possibly with a Windows path like "C:\\MyPath\\Temp\\":

char template[] = "/tmp/libxlsxwriter.XXXXXX";

from libxlsxwriter.

Alexhuszagh avatar Alexhuszagh commented on July 17, 2024

@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 the TMP or TEMP environment variables. On *Nix systems this is TMPDIR, which is how Qt does it.

An example in pseudocode looks like this:

#ifdef _WIN32
// get our drive
char *tmpdir = getenv("TMP");
if (!tmpdir) {
    tmpdir = getenv("TEMP");
}
if (!tmpdir) {
    // use getcwd here
}
#else
char *tmpdir = getenv("TMPDIR");
if (!tmpdir) {
    // use /tmp here
}
#endif

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).

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

I did not, but that implementation should only work reproducibly on *Nix systems or *Nix like systems

Can you try it. I've had a report from a MinGW user that it worked from them.

since the /tmp directory does not exist on Windows)

I guess I wasn't clear on that. You need to change the path to a writeable dir on your system.

from libxlsxwriter.

jmcnamara avatar jmcnamara commented on July 17, 2024

@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.

from libxlsxwriter.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.