-
Notifications
You must be signed in to change notification settings - Fork 113
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
unix only headers #3
Comments
Hi, On 4/05/2016 15:58, minimalisticMe wrote:
|
I do know, that the absence of unistd.h is Visual Studio specific. One could check for Visual Studio (MSVC) via |
As VS C does have neither inttypes.h nor stdint.h I usually define it myself, when I need it. In shared projects, I usually do the following:
|
It looks like unistd.h isn't needed on Windows and io.h doesn't work on On 4/05/2016 15:58, minimalisticMe wrote:
|
According to https://msdn.microsoft.com/en-us/library/323b6b3k.aspx On 4/05/2016 16:22, minimalisticMe wrote:
|
Here's how I have done it: #if defined(_MSC_VER) && _MSC_VER < 1600 Can you try building 0.2.1? On 4/05/2016 16:26, minimalisticMe wrote:
|
I will try building v0.2.1 later and give you some feedback.
|
That doesn't seem correct as Microsoft says here: On 6/05/2016 10:13, minimalisticMe wrote:
|
That is right, VS2015 does support stdint.h. |
Update: I'm now building xlsxio via VS2015 and there is support for inttypes.h (which is needed for PRIi64 in xlsxio_read.c and xlsxio_write.c, so the _#ifndef WIN32 in line 4 can be removed and #include <inttypes.h> in line 8 of xlsxio_write.c can be moved outside of _#ifndef WIN32 |
Fixed in 0.2.2 |
Hi, I see that xlsxio_write.c now contains BTW I wasn't sure whether to comment on this closed issue or open a new one. I figured I would try this first. |
Hi, |
Hi, The build did fail somewhere later. A libzip file named zip_crypto.h generated an error "no crypto backend found". I'm still trying to figure that one out, but obviously it's unrelated to the "unistd.h" issue. Thanks for the quick response. |
By the way, VS 2017 Community is free for individuals, so if you're interested in testing your code against it there's no cost involved (other than your time and significant space on your hard drive). |
I'm not that interested in having a Microsoft compiler when I can have gcc or llvm compiler that works an a lot more platforms. libzip is deprecated, from now on XLSX I/O will focus on minizip instead. Can't you just use my precompiled DLL and link with that using Visual Studio? |
I haven't tried linking with your precompiled DLL yet. I was trying to
build everything within the VS IDE. I'll give it a try using your DLL.
I saw on your Github xlsxio page that minizip is "preferred" over libzip,
but not that it was deprecated. I had previously gone to both their web
sites and got scared off of trying minizip because of some misspellings and
poor grammar. I was probably being a little paranoid that day, I'll go
back and give that a try too.
Thanks for the tips.
…On Wed, Mar 28, 2018 at 9:30 AM, Brecht Sanders ***@***.***> wrote:
I'm not that interested in having a Microsoft compiler when I can have gcc
or llvm compiler that works an a lot more platforms.
libzip is deprecated, from now on XLSX I/O will focus on minizip instead.
Can't you just use my precompiled DLL and link with that using Visual
Studio?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ai0l95Fh3WruTLVLGikIsyejjNA6l-0nks5ti5BdgaJpZM4IXK5w>
.
|
Deprecated maybe was a big word, but the fact is that LibreOffice just can't open the files generated with libzip, so I kind of had to switch to something else and minizip seems to do just fine, even though its code does seem a bit primitive. Also, it did make into it's way into Linux distributions, so it seems like it's also commonly used. |
I just did a search of the xlsxio folder that I had cloned from Github
(including all its subfolders) and I don't see any DLL files. Is your
precompiled DLL available somewhere other than your Github page ?
Also, I just finished my first pass at replacing libzip with minizip. It
had a couple of issues:
1. 'xlsxio_read.c' contains
#ifdef USE_MINIZIP
#include <minizip/unzip.h>
while 'xlsxio_read_sharedstrings.h' contains
#include <zip.h>
Since minizip keeps 'zip.h' and 'unzip.h' in the same folder, it seems like
'xlsxio_read.c' could just include <unzip.h> (i.e. the 'minizip\' preface
seems unnecessary). This doesn't cause any issue, I just had to add both
the minzip folder and its parent folder to my include paths.
2. The bigger issue is that the libzip version of 'zip.h' defines some
things that the minizip version doesn't, e.g.:
typedef struct zip_file zip_file_t;
This caused some compile errors, e.g. 'xlsxio_read.c' failed to compile
because of zip_file_t not being defined:
xlsxio_read_sharedstrings.h(28): error C2061: syntax error: identifier
'zip_file_t'
zip_file_t* zipfile;
Or do I still need to include the libzip version of 'zip.h' when building
with USE_MINIZIP defined ?
…On Wed, Mar 28, 2018 at 12:55 PM, Brecht Sanders ***@***.***> wrote:
Deprecated maybe was a big word, but the fact is that LibreOffice just
can't open the files generated with libzip, so I kind of had to switch to
something else and minizip seems to do just fine, even though its code does
seem a bit primitive. Also, it did make into it's way into Linux
distributions, so it seems like it's also commonly used.
Maybe libarchive would have been an alternative, but I wanted to avoid the
bloat since I just need zip functionality...
Let me know how it goes using the DLL from the binary downloads.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ai0l9-5vQMKIqThl-HREkykMS9FXx3jZks5ti8B_gaJpZM4IXK5w>
.
|
Are you sure you are using the latest source? It doesn't seem like it. |
Yes, I have USE_MINIZIP defined when building. The compilation is finding
the include files, but it's failing because the minizip 'zip.h' doesn't
define some things that the libzip 'zip.h' does define. And at least some
of those definitions are referenced by xlsxio.
I went back to the minizip website again and realized that the first
download link on the page gets you version 1.01 from 2005. If you want the
most recent version, you have to go get a recent version of the Zlib source
code, and it will include what I presume is the most recent version of
minizip in one of its subfolders. I had recently downloaded Zlib anyway,
so I went and checked and I have Zlib version 1.2.11 from Jan 2017. This
version of Zlib includes minizip version 1.1 from 2010. But that version
of 'zip.h' still doesn't have a definition for "zip_file_t", meaning that
'xlsxio_read.c' is still going to fail to compile with it.
Is there a later version of minizip that you know of ? (and where would I
get it ?)
…On Wed, Mar 28, 2018 at 1:48 PM, Brecht Sanders ***@***.***> wrote:
Are you sure you are using the latest source? It doesn't seem like it.
Make sure USE_MINIZIP is defined when building.
For minizip it needs the include path where minizip is a subfolder.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ai0l97qE2juT9_s_MBsBSBfkXSreiIj7ks5ti8zwgaJpZM4IXK5w>
.
|
What I meant was: are you using XLSX I/O sources version 0.2.16 ? Anyway, you shouldn't be using zip.h but minizip/zip.h and minizip/unzip.h from which zipFile and unzFile are used instead of zip_file_t, unless you are using the wrong sources or haven't compiled with /DUSE_MINIZIP |
Yes, I'm using xlsxio version 0.2.17 from 3/22/18.
I downloaded minizip 1.2.8 from your link. When I unzipped it and checked
it 'zip.h', it still says version 1.1 from Feb 2010, and still doesn't
include the definitions that xlsxio needs.
I turned Show Includes on in VS and tried to compile 'xlsxio_read.c', and
got (I added the highlights after pasting):
1>------ Build started: Project: ExampleWithXLSX, Configuration: Debug
Win32 ------
1>*xlsxio_read.c*
1>Note: including file: C:\_Projects\Git\Github\Libs\PlatformCommon\
*xlsxio\lib\xlsxio_private.h*
1>Note: including file: C:\_Projects\Git\Github\Libs\PlatformCommon\
*xlsxio\lib\xlsxio_read_sharedstrings.h*
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\stdint.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\vcruntime.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\sal.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\concurrencysal.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\vadefs.h
1>Note: including file: C:\_Projects\Git\BitBucket\Libs\PlatformCommon*\*
*minizip\zip.h*
...
1>c:\_projects\git\github\libs\platformcommon\xlsxio\lib\xlsxio_read_sharedstrings.h(28):
error C2061: syntax error: identifier 'zip_file_t'
I was thinking maybe there's some other file named 'zip.h' in my include
paths, so for a test, I renamed the minizip folder to something else and
tried to compile 'xlsxio_read.c' again:
1>------ Build started: Project: ExampleWithXLSX, Configuration: Debug
Win32 ------
1>*xlsxio_read.c*
1>Note: including file: C:\_Projects\Git\Github\Libs\PlatformCommon\
*xlsxio\lib\xlsxio_private.h*
1>Note: including file: C:\_Projects\Git\Github\Libs\PlatformCommon\
*xlsxio\lib\xlsxio_read_sharedstrings.h*
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\stdint.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\vcruntime.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\sal.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\concurrencysal.h
1>Note: including file: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\vadefs.h
1>c:\_projects\git\github\libs\platformcommon\xlsxio\lib\xlsxio_read_sharedstrings.h(5):
fatal error C1083: *Cannot open include file: 'zip.h': No such file or
directory*
So I know that there's no other 'zip.h' in my include paths, and it's
including the right 'zip.h' above, i.e. the one in the minizip folder.
On the other topic, is there someplace I can get your precompiled DLL ? I
couldn't find it in the cloned repo from Github...
Then I could try linking with your DLL rather than compiling everything.
…On Wed, Mar 28, 2018 at 3:16 PM, Brecht Sanders ***@***.***> wrote:
What I meant was: are you using XLSX I/O sources version 0.2.16 ?
Latest minizip I could find was 1.2.8 from this link:
http://www.gaia-gis.it/gaia-sins/dataseltzer-sources/
On my Debian Linux system minzip is version 1.1-8 which works just fine
too.
Anyway, you shouldn't be using zip.h but minizip/zip.h and minizip/unzip.h
from which zipFile and unzFile are used instead of zip_file_t, unless you
are using the wrong sources or haven't compiled with /DUSE_MINIZIP
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ai0l95zr0qAHys8xsgbMFwXUhJNs8IkEks5ti-FwgaJpZM4IXK5w>
.
|
minizip 1.1 should be just fine. |
You said "zip_file_t is from libzip and is not defined in minizip, which uses zipFile/unzFile instead. The USE_MINIZIP define is used to make sure the right one is used." But 'xlsxio_read.c' includes 'xlsxio_read_sharedstrings.h' with no '#ifdef USE_MINIZIP' around the include. And 'xlsxio_read_sharedstrings.h' references 'zip_file_t' with no '#ifdef USE_MINIZIP' around the reference. So if you're including the minizip 'zip.h' rather than the libzip 'zip.h', it seems like you're guaranteed to get a compile error no matter what compiler you're using. I didn't realize that I had to click on 'Releases' on the xlsxio page to get to your DLL - still learning my way around Github. |
Sorry, but I'm not seeing what you're saying in the code. |
I was actually talking about getting errors compiling 'xlsxio_read.c' rather than 'xlsxio_read_sharedstrings.c', but the result is the same. The first two lines of both files are identical: Line 5 of 'xlsxio_read_sharedstrings.h' includes <zip.h>. Since we're building with minizip rather than libzip, my include paths include the minizip folder but not the libzip folder (and I confirmed that I'm including the correct version of <zip.h>, i.e. the minizip version, as I mentioned earlier). Line 28 of 'xlsxio_read_sharedstrings.h' references 'zip_file_t', which is only defined in the libzip version of zip.h, i.e. not the version that we're including. The reference to 'zip_file_t' is not surrounded by #ifndef USE_MINIZIP. So it seems like line 28 will always generate a compile error when you build with minizip, no matter what compiler you're using. Note: in my earlier attempt to describe the issue, I had said that 'xlsxio_read_sharedstrings.h' references 'zip_file_t' without #ifdef USE_MINIZIP around the reference. It should have said without #ifndef USE_MINIZIP. I hope this clarifies what I'm trying to say. |
Got it. |
Great, thank you !
There was that one other thing, where xlsxio_read.c includes <unistd.h>
without #ifndef _WIN32 around it (you had added the conditional in
xlsxio_write.c but not in xlsxio_read.c).
I have a workaround for that.
More generally, now that I'm past the minizip-related issue, I'm finding
some compatibility-related issues.
e.g. xlsxio_read.c refers to ssize_t, which apparently is GNU-specific and
isn't defined in Visual Studio. (there is SSIZE_T, but I haven't dug in yet
to figure out if they mean the same thing).
So, if you're interested in adding VS compatibility, I can update you later
with all the things that I've had to muck with to make xlsxio work with
VS. And you can decide if you want to incorporate any of them.
If you don't care about VS, I'll just hack up my local copy of xlsxio as
needed. And/or try your precompiled DLL. And/or give MinGW a try.
Either way, thanks for all the work you've put into xlsxio and for making
it available on Github.
…On Thu, Mar 29, 2018 at 7:13 AM, Brecht Sanders ***@***.***> wrote:
Got it.
This was indeed wrong, but I hadn't noticed because I had both libzip and
minizip in my include path on all my test platforms (Windows, Linux, macOS).
I have now corrected the sources in subversion. These fixes will be part
of the next release.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ai0l9664xPcgvDPaPPIF0eUvps3lh86Hks5tjMHugaJpZM4IXK5w>
.
|
That #include <unistd.h> was needed for low level file I/O, specifically functions read/close/lseek. If you know where these are in MSVC I can look into that. By all means, if you have suggestions on how to make it compatible and this can be done without affecting other OSes I would be happy to make the necessary changes. |
hi jmporter34, can you share your VC project, I failed to compile with VC, and I tryied 2012/5? thanks. |
The only reason ssize_t is used in xlsxio_read.c is because that's the return type of read() which requires <unistd.h>. In MSVC that can be replaced with _read() from <io.h>. |
Hey,
your project uses two unix only includes:
For the unistd.h in lib/xlsxio_write.c there is an easy solution, as there is an equivalent header. Replace unistd.h (line 8) with:
For inttypes.h in lib/xlsxio_write.c and lib/xlsxio_read.c I'm still searching for a solution, as it is not officially in windows, there is a port here, which I'm not a big fan of. It would be better to find the used defines and define them with an #ifdef like the code snipped above.
e.g. (probably did not get all defines)
The text was updated successfully, but these errors were encountered: