[flashrom] Trouble cross-compiling for Windows

[Nico Huber]

Hello,

On 05.01.2018 16:13, R. Diez via flashrom wrote:
> Hi all:
> 
> First of all, many thanks for flashrom.
> 
> I found cross-compiling for Windows on my Ubuntu 16.04.3 LTS
> unnecessarily difficult. I am following the instructions on this page:
> 
>   https://flashrom.org/Windows
> 
> These are the points I would like to raise:
> 
> 1) Although that web page is a Wiki, I guess that only the flashrom team
> can modify the pages, right? That is the reason why I haven't directly
> contributed to that page yet.

No, anybody can get an account. Just inquire (including your preferred
login name) to one of these nice guys:
  Patrick <pgeorgi at google.com>
  Stefan <stefan.tauner at gmx.at>

> 
> 2) The build instructions should mention that detailed error messages go
> to file build_details.txt . The error messages written to stdout during
> the configuration phase (for example, when looking for the libusb header
> file) are very generic and do not provide enough information.

You are right, that should be mentioned.

> 
> 3) Option "-Werror" ("cc1: warnings being treated as errors") should not
> really be enabled for end-users like me. This way, you are forced to fix
> every little warning, and warnings vary with GCC versions.

No way. If you compile software in an environment (e.g. different com-
piler versions or different libraries) where it wasn't tested before,
please don't see yourself as an end-user. Providing product-quality
software without any control over the build environment is nearly im-
possible (well, at least for C programs).

> 
> In fact, there is already a warning about such a scenario in the README
> file:
> 
> ----8<----8<----
> Compiler quirks:
> 
> If you are using clang and if you want to enable only one driver, you
> may hit an overzealous compiler warning from clang. Compile with "make
> WARNERROR=no" to force it to continue and enjoy.
> ----8<----8<----

Sounds odd to me. It can happen with any compiler ofc. Patches are
welcome.

> 
> But I hear your grumble. 8-) Maybe somebody with more public exposure
> will convince you:
> 
>   https://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror/

No, didn't convince me. He writes "[...] just need the thing to build
and work when they need it, [...]". You can only ensure the former by
ignoring warnings, but you don't get any guarantee that it works. Every-
thing he writes seems to assume that all possible changes to the build
environment can only result in warnings that don't matter. But what
about warnings that do matter (e.g. a library could define different
constants in a header file that don't fit your integer variable)? So,
IMO, he has no idea what he is writing about. If there are warnings,
somebody has to look into it, or the result shouldn't be used by an
end user.

> 
> In the case of flashrom, this all translates to setting WARNERROR=no as
> the default, and WARNERROR=yes when building on your build server.

With the above in mind it translates to setting WARNERROR=no in all
environments where it is safe. Which is hard to narrow down. You could
set it for all environments where you know it is safe, but that probably
wouldn't contain cross compiling for windows.

> 
> 4) Symbol __MINGW_PRINTF_FORMAT was not defined on my system.
> Apparently, mingw does not always define it. There is advise on the
> Internet about #ifdef'ing its usage, but I did not quite understand it all.

So how did you work around? did you?

> 
> 5) I saw the following warnings:
> 
> ich_descriptors.c: In function 'prettyprint_ich_descriptor_content':
> ich_descriptors.c:142: warning: format '%5zd' expects type 'signed
> size_t', but argument 3 has type 'ssize_t'
> ich_descriptors.c:148: warning: format '%5zd' expects type 'signed
> size_t', but argument 3 has type 'ssize_t'
> 
> I tried to fix them quickly, but it turns out that the simple cast
> (signed size_t) is not valid in C. I am not sure what the best fix for
> this issue is.

Whether `signed size_t` is valid depends on the compiler and the
definition of `size_t`. It's pretty odd though, that the compiler
mentions `signed size_t` but doesn't accept it. Maybe something in
the C library headers redefines `size_t`?

> 
> 6) Please mention how to generate the HTML man page in the build
> instructions. You do not normally want to build and install as root, so
> the HTML page is the most convenient way to look at the manpage for the
> version you are building.
> 
> You need to specify both "all" and "flashrom.8.html" as targets in order
> to build the normal binary plus the HTML manpage.

Just `make flashrom.8.html` should do. We should mention that in the
README. Patches are welcome.

> 
> 7) Specifying "CONFIG_FT2232_SPI=yes" does not break the build if the
> FTDI driver is not found (if ftdi.h is not there). That is a bit lame,
> as you only realise later on when trying to use the executable that your
> programmer is not there.

I've complained about that myself some time ago. Patches are welcome.

> 
> However, if you do not turn off these two devices:
> 
>   CONFIG_CH341A_SPI=no
>   CONFIG_DEDIPROG=no
> 
> And you do not have the necessary files for libusb-1.0, then the build
> does break:
> 
>   Checking for libusb-1.0 headers... found.
>   Checking if libusb-1.0 is usable... no.
>   The following features require libusb-1.0: CONFIG_CH341A_SPI.
>   Please install libusb-1.0 or disable all features
>   mentioned above by specifying make CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=no
>   See README for more information.

This is the expected and wanted behaviour.

> 
> 8) I could not find any documentation for the configuration flags (like
> CONFIG_FT2232_SPI=yes/no). And reading the makefile is not easy.

Right, should be added to the README, IMHO. Patches are welcome.

Regards,
Nico