List Archive

Thread

Thread Index

Message

From: "Peter Bohning" <peter.bohning%gmx.com@localhost>
To: "Dieter Baron" <dillo%nih.at@localhost>
Subject: Re: mingw errors 1.3.0 1.4.0
Date: Mon, 8 Jan 2018 18:13:21 +0100

>>Yes, there are various standards, and for each requirement in them, there is a Unix variant that does not implement it fully.
 
Well that's really on those Unix variants than isn't it.
 
>>Maybe, but I still find it worthwhile to support them.
 
It's not a matter of supporting non-standard variants.  If people weren't so accommodating to the package maintainers, they would be emailing them and telling them the specific things that aren't standard.  We should all be emailing any variants that aren't working right.
 
 
>>Treating all Unix variants as one system is a fundamental misconception. Each variant, and even each version of the same platform, differ in some way.
 
It's not a fundamental misconception.  It's how it should be.
 
>>Yes it *should* be this way, but it never was and likely never will be, so it’s counterproductive to pretend that it is.
 
I'm not pretending that it is.  I wrote the mingw list first.  There's *nix, and windows, which has this supposed mingw wrapper.  This should all work perfectly.
 
>>Again, it’s pointless to speculate what should be. There *are* differences, and these are the things we check for:
 
- Check wether these functions exist: _chmod, _close, _dup, _fdopen, _fileno, _open, _setmode, _snprintf, _strdup, _stricmp, _strtoi64, _strtoui64, _umask, _unlink, clonefile, explict_bzero, explicit_memset, fileno, fseeko, ftello, getprogname, open, mkstemp, setmode, snprintf, strcasecmp, strdup, stricmp, strtoll, strtoull
 
- Check wether these include files exist: fts.h, stdbool.h, strings.h, unistd.h, inttypes.h, stdint.h, sys/types.h
 
- Check wether these types exist, and what their sizes are: __int8, int8_t, uint8_t, __int16, int16_t, uint16_t, __int32, int32_t, uint32_t, __int64, int64_t, uint64_t, short, int, long, long, off_t, size_t, ssize_t
 
- Find zlib, libbz2.
 
- Know how to build a shared library (which varies widely from system to system).
 
Do you have a concrete proposal how we achieve all this portably without autoconf/cmake? Then please let me know, because I can’t think of any. 
 
>Please note: supporting old Unix versions is a must, as is supporting various Windows versions.
 
Yes, I am aware of some of the various differences.  These are all pretty basic things.  So basically, you're telling me that all of this autoconf/cmake... and there's a new one too I saw the other day.... all of this stuff is because somehow thousand and thousands of computer programmers all with 25 years of experience, can't get 20 functions to be uniform across a handful of very similar platforms... ...  doesn't that seem strange to you?
 
>>That is not a realistic option. Neither of us is the maintainer of any standard compiler / system library, let alone of all of them. And neither of us is in a position to retroactively fix this in years old versions that are still in use.
 
To start with, every company on the planet regularly drops support for old versions.  It's great that the open source community doesn't.  Except that sometimes it does and if it's at the expense of ease of use and functionality in the present versions, it's a problem.
 
Besides this, obviously every package does not support every old version, and while autoconf/cmake/etc. might work some or even most of the time, they don't work always.  At this point, any person out there who is somehow using a version of something so old that they need to compile software for ancient versions, is probably technically competent enough to write a wrapper library for the system library.
 
>>I have seen both, and by a huge margin, the projects using autoconf/cmake are more easy to compile on a multitude of Unix variants than those that don’t. I’m not sure how our experiences can be so different.
 
There's very few projects that don't use one of these.
 
>>autoconf was first released in 1991, and it’s still in wide use. 27 years doesn’t sound like a fad to me.
 
I didn't say autoconf was a fad, I said cmake was.
 
>>It works on Windows, and that alone is a huge improvement in the context of libzip. (Anything that only works on Unix is a non-starter for a project that wants to support both.)
 
So you're saying cmake is great because it works on windows and autoconf doesn't.  Well windows and *nix, are basically the two different platforms now.  And they're different enough that no matter what, you need some kind of wrapper.  Which presumably would be mingw.  If mingw was doing its job, then autoconf would work on windows and cmake would be unnecessary.
 
>> Wow, so either we are incompetent, or the majority of the platform maintainers are.
 
This is an easy one.  The platform maintainers are all incompetent and the rest of us are too lazy to hassle them about it.
 
>>I have lined out in great detail why we use cmake. You have not provided any detail on how your proposed solution would work.
 
I think I've given the same amount of detail.
 
>>I understand your frustration with not getting cmake to work, but you are in the minority here. Did you follow up on any of my suggestions on how to fix this (using binary packages, asking on the cmake mailing lists for help on getting it to work with mingw)?
 
yours,
>dillo
 
I don't think I am in the minority.  Do an internet search for any error message and there's tons and tons and tons of people who didn't go to mailing lists and complain, because open source is free and you get what you pay for (if you're lucky), and instead went to stackexchange, quora, some forum, etc., etc..  All those problems are a huge waste of time.
 
What I might be in the minority with here is my annoyance about the whole thing.  I don't like the idea that mingw is not functioning as it should.  I don't like the idea that I have to download binaries because the source won't compile when it's supposed to be for this package that makes compiling source easier.  Are you telling me that the cmake source doesn't even compile with the latest mingw and somehow it's so great and so necessary for compiling things for windows?
 
Further, I know that all this is generally fads.  "ninja" is another one of these compiler projects.  The idiot managers at google with more money than brains hire whowever they can, and have them make up projects for themselves.  So some clever guy wrote this totally unnecessary ninja thing and google paid him handsomely for it.  That guy could have fixed up Make and mingw instead of writing whatever nonsense and think of how much hassle would have been saved by everyone.
 
Yes.  I'm in the minority because I don't immediately say gee, this thing that should work doesn't, I'll do something I shouldn't have to do to work around it.
 
As for your suggestions, I don't really have time for any of this.  I may briefly try to uninstall and reinstall mingw to find one that supposedly works with cmake.  If I can't compile cmake from source, I'm not going to use it.  If I think it's unnecessary and it won't even compile properly on the one platform it's supposedly useful for, windows/mingw, then that's it. 
 
Further, the whole point of this was because I wanted some kind of setup that, should some not-very-savvy user want to compile my software, they could do so with ease, with a short list of instructions.  Not only does that seem hopeless, given mingw, and cmake, and I haven't even gotten to the other libraries it uses, but no one is paying me for this and I'm not sure I care enough to release it.  So probably I'll mess around with it when I have a chance over the next month until I can finally get the software I wrote six months ago to compile again and then just have it for my own use.
 
And by the way I particularly hate libtool.
 
If you want my opinion, and I'm sure you don't, the problem with all of this is money.  The wrong people have all the money, so everything gets worse and worse, and not just with software.  Open source is almost a form of communism and the government should sponsor it while refraining from interfering with it's management.  Maybe China could do this more.  Or maybe cuba is the only communist government left in the world.
 
Package maintainers are always arrogant and indifferent, particularly so in the case of the ones that don't actually write software, which is always funny.  After all, no one is being paid for any of this, so there's no "customer is always right" mentality and no one cares about things being user-friendly.  Everyone is just defending their little ego turf.  And then the reward for open source software which is "copy-left", the knowledge that, forever after anyone who uses your software will also have to do the right thing and support society, well that's stomped on by companies like google, who work around it in order to sell people crap they don't need, and then pay lip-service to open source by releasing a couple pieces of unnecessary software as open source, just to muddle everything up.
 
Ask your mother to install mingw and compile this stuff from source and then don't wonder why people choose Windows decade after decade.  And then think of all that money that Microsoft puts through it's "charity" foundation, that's really just selling poison food to Mexicans and making all the Mexicans obese and diabetic for vast sums of money while all the americans complain about mexicans taking their jobs and elect a president because he wants to build a big wall.  And that's our world.  So why the hell are we wasting a single second messing with these damn computers.
 
And please, if you get a chance, figure out which parts of libzip actually don't work/won't compile on *nix and windows.  Consult some standards for these things and write some maintainers about why their setups are non-standard.
 
Thanks.
 
      Peter
Sent: Friday, January 05, 2018 at 1:27 PM
From: "Dieter Baron" <dillo%nih.at@localhost>
To: "Peter Bohning" <peter.bohning%gmx.com@localhost>
Cc: libzip-discuss%nih.at@localhost
Subject: Re: mingw errors 1.3.0 1.4.0
>>Yes, there are various standards, and for each requirement in them, there is a Unix variant that does not implement it fully.
 
Well that's really on those Unix variants than isn't it.
 
Maybe, but I still find it worthwhile to support them.
 
 
 
>>Treating all Unix variants as one system is a fundamental misconception. Each variant, and even each version of the same platform, differ in some way.
 
It's not a fundamental misconception.  It's how it should be.
 
Yes it *should* be this way, but it never was and likely never will be, so it’s counterproductive to pretend that it is.
 
 
>>Now tell me, how do I know which defines to set, which functions are available, if I only have Makefiles? Who sets these defines, so they fit the current platform? 
 
 
Besides with windows versus *nix, or things like compiler "sizeof", there should be almost no differences.
 
Again, it’s pointless to speculate what should be. There *are* differences, and these are the things we check for:
 
- Check wether these functions exist: _chmod, _close, _dup, _fdopen, _fileno, _open, _setmode, _snprintf, _strdup, _stricmp, _strtoi64, _strtoui64, _umask, _unlink, clonefile, explict_bzero, explicit_memset, fileno, fseeko, ftello, getprogname, open, mkstemp, setmode, snprintf, strcasecmp, strdup, stricmp, strtoll, strtoull
 
- Check wether these include files exist: fts.h, stdbool.h, strings.h, unistd.h, inttypes.h, stdint.h, sys/types.h
 
- Check wether these types exist, and what their sizes are: __int8, int8_t, uint8_t, __int16, int16_t, uint16_t, __int32, int32_t, uint32_t, __int64, int64_t, uint64_t, short, int, long, long, off_t, size_t, ssize_t
 
- Find zlib, libbz2.
 
- Know how to build a shared library (which varies widely from system to system).
 
Do you have a concrete proposal how we achieve all this portably without autoconf/cmake? Then please let me know, because I can’t think of any. 
 
Please note: supporting old Unix versions is a must, as is supporting various Windows versions.
 
 
>>Figuring out how to set these defines is *exactly* what autoconf/cmake are doing, but if you skip them, how do they get set? Statically in the Makefiles? Based on what? Who maintains which defines should be set for which version of which Unix variant?
 
libzip is fairly simple and "sizeof" should suffice.
 
The above list clearly shows that that’s not true.
 
 
>>I’ve seen projects that tried to maintain such a list, and they all failed, because it’s nearly impossible to get right in all cases. It’s much more robust, much easier and much less maintenance work to use a tool that lets the compiler figure it out.
 
I don't think so.  Anyone wanting to use the latest fashion in building and configuration has to learn whatever syntax and rules and then everyone else has to compile and install the build tools, etc,. etc., etc,. when whatever issues should be fixed in the standard compiler instead. 
 
That is not a realistic option. Neither of us is the maintainer of any standard compiler / system library, let alone of all of them. And neither of us is in a position to retroactively fix this in years old versions that are still in use.
 
And given that these things are always a headache, with few exceptions, I don't think it would be more robust.
 
I have seen both, and by a huge margin, the projects using autoconf/cmake are more easy to compile on a multitude of Unix variants than those that don’t. I’m not sure how our experiences can be so different.
 
 
>>Let me make it abundantly clear: a tool like cmake is *essential* for portability on Unix.
 
cmake does not seem like an improvement over autoconf, etc.,
 
It works on Windows, and that alone is a huge improvement in the context of libzip. (Anything that only works on Unix is a non-starter for a project that wants to support both.)
 
and I think ultimately autoconf should be unnecessary also.
 
Should, maybe, but isn’t.
 
 
>>I would also prefer a solution that didn’t require installing third party software, but sadly, I don’t know of any that works well across Unix and Windows. (Makefiles do not fit this requirement: they don’t work well on either platform, let alone on both.)
 
Well then we should be writing the Makefile people to improve that.  I've never had the problems with Makefiles that I've had with all these configuration tools.  With a Makefile, you can go through and find some error and fix it or add a line or use a different Makefile.  A windows and a *nix makefile, that should be all that's necessary.  With a configuration tool, libtool, autoconf, etc., it's always more difficult.
 
>>Until a better tool comes along, we will stick with cmake.
 
Well, fine, I certainly have no power over anything, it's up to you.  But I think it's a fad and libzip doesn't need that mess.
 
autoconf was first released in 1991, and it’s still in wide use. 27 years doesn’t sound like a fad to me.
 
>>Strangely, I have heard from multiple Windows users successfully building libzip using cmake. To be fair, I’m not sure if any of them used mingw.
 
Certainly I did compile 1.3.0 in the past, and it's possibly that there's some new branch of mingw that works better and the one I happened to download doesn't or is no longer really supported despite no one saying so.
 
I added #include "Wincrypt.h" to zip_random_win32.c and edited by stdio.h for some __mingw_redirect_stdio definition that wasn't being used and that got a bit farther with 1.3.2 but now there's
 
mv -f .deps/ziptool.Tpo .deps/ziptool.Po
/bin/sh ../libtool  --tag=CC   --mode=link gcc  -g -O2 -I/usr/local/include  -L/usr/local/lib -o ziptool.exe source_hole.o ziptool.o ../lib/libzip.la -lz
libtool: link: gcc -g -O2 -I/usr/local/include -o .libs/ziptool.exe source_hole.o ziptool.o  -L/usr/local/lib ../lib/.libs/libzip.a -lz
source_hole.o: In function `source_hole_cb':
C:\MinGW\msys\1.0\home\peterius\libzip-1.3.2\src/source_hole.c:527: undefined reference to `_imp__zip_error_to_data'
source_hole.o: In function `hole_free':
C:\MinGW\msys\1.0\home\peterius\libzip-1.3.2\src/source_hole.c:468: undefined reference to `_imp__zip_error_fini'
 
some linker errors and I'll try to get through that when I have a chance.
 
>>So to restate this as clearly as I can: My 25 years of experience developing portable Unix software convinced me that a tool like autoconf/cmake is the only way to maintain portability. Your proposed solution seems to completely miss the messy complexity that is Unix portability.
 
Well my 25 years of experience say that the "messy complexity" is due to people's incompetence and thoughtlessness and should be fixed.
 
Wow, so either we are incompetent, or the majority of the platform maintainers are.
 
 
I have lined out in great detail why we use cmake. You have not provided any detail on how your proposed solution would work.
 
I understand your frustration with not getting cmake to work, but you are in the minority here. Did you follow up on any of my suggestions on how to fix this (using binary packages, asking on the cmake mailing lists for help on getting it to work with mingw)?
 
yours,
dillo
 
 
 
Sent: Friday, January 05, 2018 at 12:04 PM
From: "Dieter Baron" <dillo%nih.at@localhost>
To: "Peter Bohning" <peter.bohning%gmx.com@localhost>
Cc: "Benjamin Eikel" <benjamin%eikel.org@localhost>, libzip-discuss%nih.at@localhost
Subject: Re: mingw errors 1.3.0 1.4.0
 
 
On 05.01.2018, at 17:29 , Peter Bohning <peter.bohning%gmx.com@localhost> wrote:
 
I don't know why I'm compiling Cmake either.  But certainly it should be just as easy to compile something from distributed source with a working development environment as it should be to download binary files that may or may not be appropriate.  Regardless of whether something like cmake is a reasonable solution to development for multiple platforms, certainly a compiler knows more of what platform it's on than do binary files.
 
Your experience aside,
 
You should not disregard my 25 years of experience developing portable Unix software this easily. I know what I’m talking about. 
 
 
No, you missed my point.  There should be, and are to some degree, standards such that the implementation differences among Unix variants should be irrelevant to development.
 
Yes, there are various standards, and for each requirement in them, there is a Unix variant that does not implement it fully.
 
Again, like I said, why not just have two different files, a handful of defines so that it would work on both mingw and *nix.  That's basically all this autoconf/cmake stuff does anyway.  So, somehow, you kind of missed my point.  I mean I understand, years ago I wanted to use whatever little package things and this and that, as if it was more official.  But with cmake particularly, it seems like a useless fad.
Treating all Unix variants as one system is a fundamental misconception. Each variant, and even each version of the same platform, differ in some way.
 
Now tell me, how do I know which defines to set, which functions are available, if I only have Makefiles? Who sets these defines, so they fit the current platform? 
 
Figuring out how to set these defines is *exactly* what autoconf/cmake are doing, but if you skip them, how do they get set? Statically in the Makefiles? Based on what? Who maintains which defines should be set for which version of which Unix variant?
 
I’ve seen projects that tried to maintain such a list, and they all failed, because it’s nearly impossible to get right in all cases. It’s much more robust, much easier and much less maintenance work to use a tool that lets the compiler figure it out.
 
clearly cmake is less than perfect given the difficulties I have on a relatively standard setup, and I think my point still stands that it's potentially unnecessary.
 
Let me make it abundantly clear: a tool like cmake is *essential* for portability on Unix.
 
I would also prefer a solution that didn’t require installing third party software, but sadly, I don’t know of any that works well across Unix and Windows. (Makefiles do not fit this requirement: they don’t work well on either platform, let alone on both.)
 
Until a better tool comes along, we will stick with cmake.
 
I will probably mess with that some more... and if I get lazy then I will try to find binary packages for cmake, I guess... but I'm sure there will be more problems after that.  None of this stuff ever works.
Strangely, I have heard from multiple Windows users successfully building libzip using cmake. To be fair, I’m not sure if any of them used mingw.
 
So to restate this as clearly as I can: My 25 years of experience developing portable Unix software convinced me that a tool like autoconf/cmake is the only way to maintain portability. Your proposed solution seems to completely miss the messy complexity that is Unix portability.
 
yours,
dillo
 
 
Sent: Thursday, January 04, 2018 at 1:41 PM
From: "Benjamin Eikel" <benjamin%eikel.org@localhost>
To: "Peter Bohning" <peter.bohning%gmx.com@localhost>
Cc: libzip-discuss%nih.at@localhost
Subject: Re: mingw errors 1.3.0 1.4.0
Dear Peter,

Am Donnerstag, 4. Januar 2018, 19:22:20 CET schrieb Peter Bohning:
> Sorry. Didn't mean to sound hostile, I'm mostly just sarcastic. I've just
> been doing this stuff for so many years and nothing ever changes. I know
> most people use autoconf, I've always kind of wondered why. It goes
> through and checks for all these types and sizes and which functions are
> supported... I don't really understand why POSIX compliance isn't... I
> don't know, more complete and supported by the government or something...
> most of the setups and operating systems are basically the same, I don't
> get why this is all such a mess.
> But here... there's like 10 different types here, right? Wouldn't it be
> easier to put them in separate files, and have a windows and a *nix
> compile? I mean that's basically all there is now: windows and *nix... I'm
> not even saying anything about libzip here, this whole thing just seems
> crazy to me... this is 2018... are you telling me I have to compile this
> whole other cmake thing, which also won't compile on my mingw, just to
> define like ten different types for libzip? And that's the same problem
> with autoconf... it's like you sit there waiting for it to run through
> configure and all these types, and the actual program uses a handful of
> them...
> I would like the application I wrote to be easy for people to compile and
> install... if I didn't, I would write my own makefile for libzip, quite
> frankly, and just define the types as necessary.
> I don't know what to do and I don't really have time to deal with it. cmake
> won't compile. I guess it doesn't matter. I'm not getting paid for my
> application, why go through this hassle. Yeah I guess maybe I'll write my
> own makefile for libzip, it can't be more trouble than getting cmake to
> compile.

I followed this mailing thread and I cannot understand why you are trying to
compile CMake at all. Lubomir already told you that you can download [1] a
pre-built CMake binary release for Windows. You can choose from a Windows
win64-x64 [2] or win32-x86 [3] Installer, or the ZIP files on CMake's download
page.
Furthermore, concerning your other remarks about CMake: from my experience as
a software developer as well as as a user building free software from source,
CMake is a very helpful (build a project for the IDE of your choice), flexible
(use different compilers, find libraries on many platforms), and user friendly
(usable on command line as well as with Qt GUI) tool.

Kind regards
Benjamin

[1] https://cmake.org/download/
[2] https://cmake.org/files/v3.10/cmake-3.10.1-win64-x64.msi
[3] https://cmake.org/files/v3.10/cmake-3.10.1-win32-x86.msi

> Sent: Thursday, January 04, 2018 at 8:06 AM
> From: "Dieter Baron" <dillo%nih.at@localhost>
> To: "Peter Bohning" <peter.bohning%gmx.com@localhost>
> Cc: "libzip mailing list" <libzip-discuss%nih.at@localhost>
> Subject: Re: mingw errors 1.3.0 1.4.0
> hi,
>
> On 04.01.2018, at 03:04 , Peter Bohning <peter.bohning%gmx.com@localhost> wrote:
>
> And libzip is not that complicated. What does it need cmake for anyway?
> Just for fun? Just to stay trendy?
> We need to check which functions and types the platform libzip is compiled
> on supports. There are two common tools to do this: autoconf/automake and
> cmake. Since we want to support Windows and autoconf needs sh(1) (which is
> not available on Windows), cmake is our only practical option.
> BTW, I would really appreciate it if you could tone it down a little; you
> come across as rather aggressive.
> yours,
> dillo
>
 

Made by MHonArc.