All,
Compile went without issue: The compiled code worked on the test cases I
currently have (which have been functionally unchanged for over a year).
Thank You!
Matt
On Mon, Jul 27, 2015 at 5:52 PM, James A. Peltier wrote:
> - Original Message -
> | On 27/07/15 18:05, James A. Peltie
- Original Message -
| On 27/07/15 18:05, James A. Peltier wrote:
| > Now I wind up with
| >
| >
| > [BUILD] bin/vsprintf_test.o
| > [BUILD] bin/x509_test.o
| > [BUILD] bin/aes.o
| > cc1: warnings being treated as errors
| > crypto/aes.c: In function ‘aes_encrypt_rounds’:
| > cryp
On 27/07/15 18:05, James A. Peltier wrote:
Now I wind up with
[BUILD] bin/vsprintf_test.o
[BUILD] bin/x509_test.o
[BUILD] bin/aes.o
cc1: warnings being treated as errors
crypto/aes.c: In function ‘aes_encrypt_rounds’:
crypto/aes.c:165: error: dereferencing pointer ‘first.8’ does break
All,
Confirming James results on a RHEL/CentOS 6.6 platform... I'm getting the
same thing.
Best,
Matt
On Mon, Jul 27, 2015 at 12:05 PM, James A. Peltier wrote:
> Now I wind up with
>
>
>
> [BUILD] bin/vsprintf_test.o
> [BUILD] bin/x509_test.o
> [BUILD] bin/aes.o
> cc1: warnings being t
Now I wind up with
[BUILD] bin/vsprintf_test.o
[BUILD] bin/x509_test.o
[BUILD] bin/aes.o
cc1: warnings being treated as errors
crypto/aes.c: In function ‘aes_encrypt_rounds’:
crypto/aes.c:165: error: dereferencing pointer ‘first.8’ does break
strict-aliasing rules
crypto/aes.c:165: note:
On 26/07/15 21:52, Michael Brown wrote:
It's not a change in build requirements, just a debatable warning that happens not to
show up in current gcc versions. It should be fixable by just adding "(void)"
to the start of the offending line.
Will push a fix tomorrow.
Should now be fixed:
ht
On 26 July 2015 18:21:18 BST, Matthew Helton wrote:
>James,
>
>Agreed. Yes, and we need the requirements for GCC and other packages
>updated as well. It's fine that a newer platform is needed, but it
>needs to
>be documented.
>
>Michael, Robin?
>
>Matt
>
>
>On Sun, Jul 26, 2015 at 12:12 PM, James
James,
Agreed. Yes, and we need the requirements for GCC and other packages
updated as well. It's fine that a newer platform is needed, but it needs to
be documented.
Michael, Robin?
Matt
On Sun, Jul 26, 2015 at 12:12 PM, James A. Peltier wrote:
> The question is, is this intentional code br
The question is, is this intentional code breakage or a mistake? Is CentOS 6 no
longer supported as a build platform for iPXE? Thankfully I also run an HPC
cluster where I already had newer versions of GCC compiled for other things to
test with or I wouldn't have found it so quickly.
- Ori
James,
Thank you; it's fixed by migrating to a CentOS 7 build and gcc 4.8.3; as
mentioned before in this list you need xz-devel installed or the make will
croak at "util/zbin lzma.h: No such file or directory"
Best,
Matt
On Sat, Jul 25, 2015 at 7:38 PM, James A. Peltier wrote:
> Ya, I have t
Ya, I have the same problem on a CentOS 6 box using the stock GCC, however,
newer versions of GCC, for example 4.9.2 do not exhibit the problem.
- Original Message -
| When making:
| $ make
| [DEPS] core/xferbuf.c
| [BUILD] bin/xferbuf.o
| cc1: warnings being treated as errors
| core/x
When making:
$ make
[DEPS] core/xferbuf.c
[BUILD] bin/xferbuf.o
cc1: warnings being treated as errors
core/xferbuf.c: In function ‘xfer_buffer’:
core/xferbuf.c:312: error: value computed is not used
make: *** [bin/xferbuf.o] Error 1
$
System GCC: gcc.x86_64 4.4.7-11.e
12 matches
Mail list logo
