>>> - mingw debug and shared builds in master. >> >> While I can confirm problem with shared (fixable with attached >> patch, please double-check), I can't confirm problem with debug >> (please elaborate). > > I just opened a pull request on GitHub [0] to add your patch for > mingw shared builds and another one to fix clang debug builds for > master. Let's see what Travis thinks of it.
The other modification was submitted by Emilia to internal system 4 days ago. Or in other words fixes will show up. But I'd like to use this opportunity to challenge the choice of using --strict-warnings in [all] CI scenarios. Two points. - Just like everything else warning system is subject to bugs and is a changing field. For example -Wshadow complains about local variables shadowing functions. It appeared in specific gcc version and then was removed. Then mingw compiler complains about missing prototypes in a number of *_asn1 modules. I fail to understand why only mingw compiler. - While strict adherence to every letter of the standard is a good thing, some code is (and always will be) system-specific and it might be impractical to treat it otherwise. For example mingw compiler complains about %I64i format string being non-standard. There is nothing that can be done about it (except for implementing own subroutine, but that would be definition of impractical). Another example is complain about assignment of GetProcAddress to void *. Well, it is meaningful warning and we do address it in other non-Win32 places. But how do you handle it in truly standard manner on 32-bit Win32? When you can use GetProcAddress to pull references to either cdecl or stdcall, per-definition implementation-specific thing? [BTW, is it possible that above mentioned missing prototypes thing is because of this?] Note that I'm not saying that warnings should not be fixed. I'm saying that it's impractical to treat all of them equally (not to mention that there are legitimate false positives after all), and CI might be not the right place to catch them. I would even say that on CI it is more valuable to aim for running tests than to stop on warnings. Or maybe it's not mutually exclusive? As for running tests in the context of query, i.e. mingw cross-compilation on Linux. It actually was possible to perform under 'wine' before and surely can be fixed now. Is 'wine' an option in this case? > Mingw's debug builds are still broken, but now the following error > message is shown: > >> cc1: error: command line option ‘-foutput-class-dir=-DL_ENDIAN’ >> is valid for Java but not for C [-Werror] > > The problem is that `-d` is a `./config` option, but in the case of > mingw it is passed directly to `./Configure` which thinks it's a > compiler flag so then gcc gets confused. A solution would be to > somehow detect the mingw cross compilation from `./config` so that > we would use it for mingw builds too, but I'm not sure what the > best way to do that would be (and on top of this we still have the > mingw warnings problem). I don't understand. Last modifications to .travis.yml switch from ./config to ./Configure on mingw, so that where does this ./config passing -d to ./Configure come from? I'd say that the switch is appropriate, because ./config was never meant and is hardly proper choice for cross-compiler cases. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
