On linux, is it possible to use 7z.so, meaning to load the library and invoke all needed methods as they are defined in the headers, but without using any other p7zip sources, without linking the application to any of them?
Let me clarify the question. The Client7z example, which demonstrates how to use the 7z library, links against a number of other source files from the repository. All these files are LGPL, which means that I cannot mix them with the proprietary code in my application.
This leaves me two alternatives. First, to write the utility code which is needed in order to use 7z.so from scratch. However I have a feeling that it might be not completely possible, for example PropVariant conversions directly require using the relevant source files, which might not be exported by 7z.so library. Besides, I really don't like the idea of reinventing the wheel, e.g. writing my own stream classes instead of those offered by p7zip.
The second solution could be creating another library which will include all those files that I need in order to work with 7z.so. Even if it will be LGPLed, it won't mix with the proprietary code. Alternatively, all this code can be linked with the 7z.so itself, providing necessary export directives.
I guess that the problem isn't so acute on Windows if the code uses standard system COM libraries and types.
To summarize, I have a feeling that the 7z.so interface on linux requires an additional library code in order to use it, however due to license there is no way to mix it in a proprietary code. I admit that I can be missing something though.
Can you suggest a design solution for this problem (assuming that my assumptions are correct of course)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that there is public domain LZMA SDK that includes Client7z and some other files.
But it's for Windows. I suppose some of these files are common with p7zip.
But p7zip is developed by another developer.
If p7zip's developer doesn't provide another license for p7zip's code (that differs from 7-zip) - maybe you must use way 2 - intermediate .so file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW, I've added new conversion code for DosTime for Windows CE support.
So maybe you can reduce wine code.
But there are one problem with time functions. My FileTimeToDosTime rounds up:
45 sec -> 46 sec.
44.2 sec -> 46 sec.
But FileTimeToUnixTime rounds down:
44.8 sec -> 44 sec.
Maybe FileTimeToUnixTime also should rounds up. But maybe it's not good idea to change that code, since "update" operations can use timestamps to decide what files to compress.
How does your current FileTimeToDosTime work for timestamps like 44.2 sec?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On linux, is it possible to use 7z.so, meaning to load the library and invoke all needed methods as they are defined in the headers, but without using any other p7zip sources, without linking the application to any of them?
Let me clarify the question. The Client7z example, which demonstrates how to use the 7z library, links against a number of other source files from the repository. All these files are LGPL, which means that I cannot mix them with the proprietary code in my application.
This leaves me two alternatives. First, to write the utility code which is needed in order to use 7z.so from scratch. However I have a feeling that it might be not completely possible, for example PropVariant conversions directly require using the relevant source files, which might not be exported by 7z.so library. Besides, I really don't like the idea of reinventing the wheel, e.g. writing my own stream classes instead of those offered by p7zip.
The second solution could be creating another library which will include all those files that I need in order to work with 7z.so. Even if it will be LGPLed, it won't mix with the proprietary code. Alternatively, all this code can be linked with the 7z.so itself, providing necessary export directives.
I guess that the problem isn't so acute on Windows if the code uses standard system COM libraries and types.
To summarize, I have a feeling that the 7z.so interface on linux requires an additional library code in order to use it, however due to license there is no way to mix it in a proprietary code. I admit that I can be missing something though.
Can you suggest a design solution for this problem (assuming that my assumptions are correct of course)?
Note that there is public domain LZMA SDK that includes Client7z and some other files.
But it's for Windows. I suppose some of these files are common with p7zip.
But p7zip is developed by another developer.
If p7zip's developer doesn't provide another license for p7zip's code (that differs from 7-zip) - maybe you must use way 2 - intermediate .so file.
As the developper of p7zip, I give to p7zip the same license as in 7-zip for all the files that came from 7-zip.
But p7zip has some files ( wine\_date\_and\_time.cpp and wine\_GetXXXDefaultLangID.cpp) from wine (www.winehq.org) which is LGPL.
For example, Client7z use wine_date_and_time.cpp that has code from wine…
BTW, I've added new conversion code for DosTime for Windows CE support.
So maybe you can reduce wine code.
But there are one problem with time functions. My FileTimeToDosTime rounds up:
45 sec -> 46 sec.
44.2 sec -> 46 sec.
But FileTimeToUnixTime rounds down:
44.8 sec -> 44 sec.
Maybe FileTimeToUnixTime also should rounds up. But maybe it's not good idea to change that code, since "update" operations can use timestamps to decide what files to compress.
How does your current FileTimeToDosTime work for timestamps like 44.2 sec?