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:
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.
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.
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.
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<----
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/
In the case of flashrom, this all translates to setting WARNERROR=no as the default, and WARNERROR=yes when building on your build server.
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.
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.
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.
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.
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.
8) I could not find any documentation for the configuration flags (like CONFIG_FT2232_SPI=yes/no). And reading the makefile is not easy.
Please copy me on any answers, as I am not subscribed to this mailing list.
Regards, R. Diez
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:
These are the points I would like to raise:
- 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@google.com Stefan stefan.tauner@gmx.at
- 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.
- 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.
- 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?
- 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`?
- 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.
- 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.
- 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
-
Nico Huber -
R. Diez