[Bug binutils/29964] New: When will binutils support Windows on ARM (aarch64-pe) ?
https://sourceware.org/bugzilla/show_bug.cgi?id=29964 Bug ID: 29964 Summary: When will binutils support Windows on ARM (aarch64-pe) ? Product: binutils Version: unspecified Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: brecht at sanders dot org Target Milestone: --- Is it known when the aarch64 PE target (used by Windows on ARM, and supported by MinGW-w64) will be supported in binutils? I recently came across https://sourceware.org/pipermail/binutils/2021-December/118998.html which seems to pretty much do what is needed (except for pe-bigobj-aarch64 support), but it seems like that patch was never accepted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|NEW |RESOLVED --- Comment #6 from Alan Modra --- Never mind, I did it for you. ChangeLog file entries are no longer required, but I like to put one in the git log entry (without the date/author which are usually redundant) for the discipline it forces on me to ensure I'm committing what I mean to commit.. Also, having the PR number in the git log formatted as for a ChangeLog entry means the commit is automatically echoed to bugzilla. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=38afcc0c69d2f547d47fdba12ed5b090ae2b976e commit 38afcc0c69d2f547d47fdba12ed5b090ae2b976e Author: Paul Koning Date: Wed Jan 4 22:29:00 2023 + PR29963, PDP11 link produces spurious relocation truncated messages PDP11 is a 16-bit processor with 16-bit logical addresses. Therefore wrapping should be allowed on the 16-bit relocs, and may as well be allowed for the 32-bit reloc too. PR 29963 * pdp11.c (howto_table_pdp11): Use complain_overflow_dont. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 --- Comment #4 from Paul Koning --- I will do that, will have to refresh my memory about procedures. Do I need to send the change to the list? Do I have to update ChangeLog or is that automatic? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 Alan Modra changed: What|Removed |Added Last reconfirmed||2023-01-05 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Alan Modra --- Please apply your fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 Paul Koning changed: What|Removed |Added Build||aarch64-apple-darwin21.6.0 Target||pdp11-dec-aout Host||aarch64-apple-darwin21.6.0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/22859] gas seems to misassemble cmp r, $label+offset on PDP-11 with reproducer
https://sourceware.org/bugzilla/show_bug.cgi?id=22859 Paul Koning changed: What|Removed |Added CC||paulkoning at comcast dot net --- Comment #4 from Paul Koning --- I don't see a misassembly here. "boing" is at address 4, so the expression boing+1 translates to 5. But the relocation truncated error messages are wrong; that is a case of not following the pdp11 address arithmetic rules. I just entered bug #29963 for that with a proposed simple patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] New: PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 Bug ID: 29963 Summary: PDP11 link produces spurious relocation truncated messages Product: binutils Version: 2.41 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: paulkoning at comcast dot net Target Milestone: --- Created attachment 14555 --> https://sourceware.org/bugzilla/attachment.cgi?id=14555=edit Reproducer source file In some large programs "relocation truncated" errors appear. It turns out the PDP11 linker asks for signed overflow checking, which is not correct because PDP11 addresses are unsigned. Unsigned checking is not correct either because wrap is valid in certain cases. The DEC linker does 16 bit relocation arithmetic with silent wrapping, and ld should do likewise. Attached: reproducer and patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 --- Comment #2 from Paul Koning --- Created attachment 14557 --> https://sourceware.org/bugzilla/attachment.cgi?id=14557=edit Proposed fix -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29963] PDP11 link produces spurious relocation truncated messages
https://sourceware.org/bugzilla/show_bug.cgi?id=29963 --- Comment #1 from Paul Koning --- Created attachment 14556 --> https://sourceware.org/bugzilla/attachment.cgi?id=14556=edit Reproducer link script -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #14 from Dennis Clarke --- Follow up : the compile completes with a pile of warnings in various places. Nothing too severe. The test suite may take a very long time. Dennis -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #13 from Dennis Clarke --- (In reply to Nick Clifton from comment #12) > (In reply to Dennis Clarke from comment #10) > > > I will give that patch a whirl and see what happens. This will just be > > a moment or two ... or three. > > Good luck. From the looks of things you will probably need to tweak the > patch a little so that it actually works with the defines provided by the > SunOS headers. If it does work, please let us have the correct version of > the patch. > > Cheers > Nick I am making progress in that I did something a bit more deliberate : $ diff -u include/plugin-api.h.orig include/plugin-api.h --- include/plugin-api.h.orig 2022-07-08 09:46:48.0 + +++ include/plugin-api.h2023-01-04 15:59:44.085042000 + @@ -48,9 +48,17 @@ #define PLUGIN_PDP_ENDIAN 1 #endif #else -/* Older GCC releases (<4.6.0) can make detection from glibc macros. */ +/* Older GCC releases (<4.6.0) can make detection from system C library macros. */ #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) #include +#elif defined(__SVR4) && defined(__sun) +#include +#if defined(_BIG_ENDIAN) +#define PLUGIN_BIG_ENDIAN 1 +#elif defined(_LITTLE_ENDIAN) +#define PLUGIN_LITTLE_ENDIAN 1 +#endif +#endif #ifdef __BYTE_ORDER #if __BYTE_ORDER == __LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 @@ -58,7 +66,7 @@ #define PLUGIN_BIG_ENDIAN 1 #endif #endif -#endif + /* Include all necessary header files based on target. */ #if defined(__SVR4) && defined(__sun) #include $ That solves the compile problem for elflink.c but who knows what will happen next? The compile is running. On a SPARCStation 20 it is walking briskly. However it is ... walking along. I will keep posting updates as they happen. Oh, also I need to test on Solaris 10 and 11.3 and 11.4 likely. All of this to get a better assember! -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29631] [display text] Incorrect percentages shown in the source and disassembly output
https://sourceware.org/bugzilla/show_bug.cgi?id=29631 Kurt Goebel changed: What|Removed |Added Priority|P2 |P3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #12 from Nick Clifton --- (In reply to Dennis Clarke from comment #10) > I will give that patch a whirl and see what happens. This will just be > a moment or two ... or three. Good luck. From the looks of things you will probably need to tweak the patch a little so that it actually works with the defines provided by the SunOS headers. If it does work, please let us have the correct version of the patch. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #11 from Nick Clifton --- Created attachment 14554 --> https://sourceware.org/bugzilla/attachment.cgi?id=14554=edit Proposed patch *sigh* Ok, how about this patch instead ? (I added the blank lines to the plugin-api.h to make things easier to read). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961
--- Comment #10 from Dennis Clarke ---
For the sake of reference this is a very old machine and the OS is also
very very old. Runs fine.
Firstly the sys/byteorder.h merely asks if _BIG_ENDIAN is defined :
n$ /usr/xpg4/bin/nl -b a -n rz /usr/include/sys/byteorder.h
01 /* Copyright (c) 1984, 1986, 1987, 1988, 1989 AT */
02 /*All Rights Reserved */
03
04 /* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT */
05 /* The copyright notice above does not evidence any*/
06 /* actual or intended publication of such source code. */
07
08 #ifndef _SYS_BYTEORDER_H
09 #define _SYS_BYTEORDER_H
10
11 #pragma ident "@(#)byteorder.h1.1498/04/19 SMI" /*
SVr4.0 1.2 */
12
13 #include
14
15 #ifdef __cplusplus
16 extern "C" {
17 #endif
18
19 /*
20 * PROPRIETARY NOTICE (Combined)
21 *
22 * This source code is unpublished proprietary information
23 * constituting, or derived under license from AT's Unix(r) System
V.
24 * In addition, portions of such source code were derived from
Berkeley
25 * 4.3 BSD under license from the Regents of the University of
26 * California.
27 *
28 *
29 *
30 * Copyright Notice
31 *
32 * Notice of copyright on this source code product does not indicate
33 * publication.
34 *
35 * (c) 1986,1987,1988,1989 Sun Microsystems, Inc.
36 * (c) 1983,1984,1985,1986,1987,1988,1989 AT
37 * All rights reserved.
38 */
39
40 /*
41 * macros for conversion between host and (internet) network byte order
42 */
43
44 #if defined(_BIG_ENDIAN) && !defined(ntohl) && !defined(lint)
45 /* big-endian */
46 #define ntohl(x)(x)
47 #define ntohs(x)(x)
48 #define htonl(x)(x)
49 #define htons(x)(x)
50
51 #elif !defined(ntohl) /* little-endian */
52
53 #ifndef _IN_PORT_T
54 #define _IN_PORT_T
55 typedef uint16_t in_port_t;
56 #endif
57
58 #ifndef _IN_ADDR_T
59 #define _IN_ADDR_T
60 typedef uint32_t in_addr_t;
61 #endif
62
63 #if !defined(_XPG4_2) || defined(__EXTENSIONS__) || defined(_XPG5)
64 extern uint32_t htonl(uint32_t);
65 extern uint16_t htons(uint16_t);
66 extern uint32_t ntohl(uint32_t);
67 extern uint16_t ntohs(uint16_t);
68 #else
69 extern in_addr_t htonl(in_addr_t);
70 extern in_port_t htons(in_port_t);
71 extern in_addr_t ntohl(in_addr_t);
72 extern in_port_t ntohs(in_port_t);
73 #endif /* !defined(_XPG4_2) || defined(__EXTENSIONS__) ||
defined(_XPG5) */
74 #endif
75
76 #ifdef __cplusplus
77 }
78 #endif
79
80 #endif /* _SYS_BYTEORDER_H */
n$
The real meat and potatoes we are looking for is in sys/isa_defs.h which
seems to focus on the question : is this SPARC or Intel ia64 or some
variation on x86? I don't see anything about PowerPC so lets forget that
for now. Ultimately we could check for __i386 or __sparc and that sorts
out the _BIG_ENDIAN or _LITTLE_ENDIAN :
n$ /usr/xpg4/bin/nl -b a -n rz /usr/include/sys/isa_defs.h
01 /*
02 * Copyright (c) 1993-1999 by Sun Microsystems, Inc.
03 * All rights reserved.
04 */
05
06 #ifndef _SYS_ISA_DEFS_H
07 #define _SYS_ISA_DEFS_H
08
09 #pragma ident "@(#)isa_defs.h 1.2099/05/04 SMI"
10
11 /*
12 * This header file serves to group a set of well known defines and to
13 * set these for each instruction set architecture. These defines may
14 * be divided into two groups; characteristics of the processor and
15 * implementation choices for Solaris on a processor.
16 *
17 * Processor Characteristics:
18 *
19 * _LITTLE_ENDIAN / _BIG_ENDIAN:
20 * The natural byte order of the processor. A pointer to an int
points
21 * to the least/most significant byte of that int.
22 *
23 * _STACK_GROWS_UPWARD / _STACK_GROWS_DOWNWARD:
24 * The processor specific direction of stack growth. A push onto
the
25 * stack increases/decreases the stack pointer, so it stores data
at
26 * successively higher/lower addresses. (Stackless machines
ignored
27 * without regrets).
28 *
29 * _LONG_LONG_HTOL / _LONG_LONG_LTOH:
30 * A pointer to a long long points to the most/least significant
long
31 * within that long long.
32 *
33 * _BIT_FIELDS_HTOL / _BIT_FIELDS_LTOH:
34 * The C compiler assigns bit fields from the high/low to the
low/high end
35 * of an int (most to least significant vs. least to most
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #9 from Dennis Clarke --- (In reply to Nick Clifton from comment #5) > (In reply to Andreas Schwab from comment #4) > > No, it defines _BYTE_ORDER and _BIG_ENDIAN. > > Ah - so the issue is this line: > > #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) > > Presumably we need to test for SunOS. Would this work: > > #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) > || defined(__SUNOS__) > > Or: > > #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) > || defined(SunOS) > > Would that work ? > > Dennis - are you able to test this idea and see if it helps ? Yes indeed! I was sort of waiting for the glibc dust to settle and then begin a new configure etc. One must be patient with these old machines. For that matter I am no spring chicken myself. More like some slow moving old silverback UNIX ape :) I am working on it! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #8 from Andreas Schwab --- __BYTE_ORDER is not the same as _BYTE_ORDER. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #7 from Nick Clifton --- (In reply to Andreas Schwab from comment #6) > SunOS is not related to glibc at all. > > #if defined(__SVR4) && defined(__sun) > #include > #endif So diff --git a/include/plugin-api.h b/include/plugin-api.h index 379828ba854..4e0a4c89584 100644 --- a/include/plugin-api.h +++ b/include/plugin-api.h @@ -48,9 +48,12 @@ #define PLUGIN_PDP_ENDIAN 1 #endif #else -/* Older GCC releases (<4.6.0) can make detection from glibc macros. */ +/* Older GCC releases (<4.6.0) can make detection from system C lirbary macros. */ #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) #include +#elif defined(__SVR4) && defined(__sun) +#include +#endif #ifdef __BYTE_ORDER #if __BYTE_ORDER == __LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 @@ -58,7 +61,7 @@ #define PLUGIN_BIG_ENDIAN 1 #endif #endif -#endif + /* Include all necessary header files based on target. */ #if defined(__SVR4) && defined(__sun) #include How about this patch ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #6 from Andreas Schwab --- SunOS is not related to glibc at all. #if defined(__SVR4) && defined(__sun) #include #endif -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #5 from Nick Clifton --- (In reply to Andreas Schwab from comment #4) > No, it defines _BYTE_ORDER and _BIG_ENDIAN. Ah - so the issue is this line: #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) Presumably we need to test for SunOS. Would this work: #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) || defined(__SUNOS__) Or: #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) || defined(SunOS) Would that work ? Dennis - are you able to test this idea and see if it helps ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #4 from Andreas Schwab --- No, it defines _BYTE_ORDER and _BIG_ENDIAN. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #3 from Nick Clifton --- (In reply to Andreas Schwab from comment #2) > This is SunOS, nothing related to glibc. Sorry - I was going by the comment in the fragment from plugin-api.h. So - presumably SunOS's version of endian.h does not defined __BYTE_ORDER. Or it does define it, but not something that matches __BIG_ENDIAN. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 --- Comment #2 from Andreas Schwab --- This is SunOS, nothing related to glibc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Dennis, Well it is nice to hear that these big iron boxes are still be used. > ../../binutils-2.39/bfd/bfd.c: In function ‘_bfd_abort’: > ../../binutils-2.39/bfd/bfd.c:1671:1: warning: ‘noreturn’ function does return This is a little bit strange, but probably not important. Possibly the function _exit() is not defined/prototyped on your system, which might lead to link time issues. But let's see if we can get there first. > ../../binutils-2.39/bfd/../include/plugin-api.h:162:2: error: #error "Could > not detect architecture endianess" > I am guessing that PLUGIN_BIG_ENDIAN simply did not get set somewhere? Correct - it is set at the start of plugin-api.h, using macros defined by gcc and/or glibc: /* Older GCC releases (<4.6.0) can make detection from glibc macros. */ #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__) #include #ifdef __BYTE_ORDER #if __BYTE_ORDER == __LITTLE_ENDIAN #define PLUGIN_LITTLE_ENDIAN 1 #elif __BYTE_ORDER == __BIG_ENDIAN #define PLUGIN_BIG_ENDIAN 1 #endif #endif So my guess is that your glibc version is not defining __BYTE_ORDER in As a suggestion, can you configure with: CFLAGS="-D__BIG_ENDIAN=1 -D__BYTE_ORDER=__BIG_ENDIAN" added to the command line, and see if this helps ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29961] New: /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess"
https://sourceware.org/bugzilla/show_bug.cgi?id=29961 Bug ID: 29961 Summary: /include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess" Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dclarke at blastwave dot org Target Milestone: --- Firstly this may not be a bug at all. the real issue may be that I have a very old machine which is an architecture that no one seems to support anymore. However I feel it can not hurt to at least file this and then receive "sorry, we don't work in the Smithsonian." :) So the machine is, yes, really : n$ n$ uname -a SunOS nix 5.8 Generic_117350-62 sun4m sparc SUNW,SPARCstation-20 n$ n$ psrinfo -v Status of virtual processor 0 as of: 01/04/23 09:39:23 on-line since 07/16/22 09:39:20. The sparc processor operates at 60 MHz, and has a sparc floating point processor. Status of virtual processor 2 as of: 01/04/23 09:39:23 on-line since 12/19/22 13:48:51. The sparc processor operates at 60 MHz, and has a sparc floating point processor. n$ n$ gcc --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. n$ These units make lovely room heaters and you would be surprised that they still run just fine. In any case there is plenty of GNU type open software packages that build and test fine. I simply felt that a more recent GNU as would be of value. I know that the Sun linker ld is what I should stay with but the GNU as is far better at many things. Enough said there. I have tried both binutils-2.23.2 as well as binutils-2.39 where both of these report a similar condition, however the 2.39 merely marches onwards and then dies soon afterwards. This is the 2.23.2 fail : . . . libtool: compile: /opt/csw/gcc4/bin/gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.23.2/bfd -I. -I../../binutils-2.23.2/bfd -I../../binutils-2.23.2/bfd/../include -DHAVE_bfd_elf32_sparc_sol2_vec -DHAVE_bfd_elf64_sparc_sol2_vec -DHAVE_sunos_big_vec -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec -I./../intl -DBINDIR=\"/opt/bw/bin\" -I/opt/bw/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -m32 -g -O0 -fno-builtin -mno-app-regs -mhard-float -mno-faster-structs -mstd-struct-return -mcpu=v8 -mno-v8plus -mno-vis -MT bfd.lo -MD -MP -MF .deps/bfd.Tpo -c ../../binutils-2.23.2/bfd/bfd.c -o bfd.o cc1: warnings being treated as errors ../../binutils-2.23.2/bfd/bfd.c: In function ‘_bfd_abort’: ../../binutils-2.23.2/bfd/bfd.c:1047:1: error: ‘noreturn’ function does return gmake[4]: *** [Makefile:1575: bfd.lo] Error 1 gmake[4]: Leaving directory '/opt/bw/build/binutils-2.23.2_SunOS5.8_sun4m.003/bfd' gmake[3]: *** [Makefile:1617: all-recursive] Error 1 gmake[3]: Leaving directory '/opt/bw/build/binutils-2.23.2_SunOS5.8_sun4m.003/bfd' gmake[2]: *** [Makefile:1108: all] Error 2 gmake[2]: Leaving directory '/opt/bw/build/binutils-2.23.2_SunOS5.8_sun4m.003/bfd' gmake[1]: *** [Makefile:2505: all-bfd] Error 2 gmake[1]: Leaving directory '/opt/bw/build/binutils-2.23.2_SunOS5.8_sun4m.003' gmake: *** [Makefile:838: all] Error 2 So let's not bother with that old version. Moving onwards to the very recent 2.39 where I also see this as a warning : gmake[4]: Entering directory '/opt/bw/build/binutils-2.39_SunOS5.8_sun4m.001/bfd' rm -f bfd-tmp.h cp bfd-in3.h bfd-tmp.h /export/home/dclarke/bin/bash ../../binutils-2.39/bfd/../move-if-change bfd-tmp.h bfd.h rm -f bfd-tmp.h touch stmp-bfd-h CC archive.lo CC archures.lo CC bfd.lo ../../binutils-2.39/bfd/bfd.c: In function ‘_bfd_abort’: ../../binutils-2.39/bfd/bfd.c:1671:1: warning: ‘noreturn’ function does return CC bfdio.lo CC bfdwin.lo CC cache.lo . . . . Then we get a kaboom fail at : CC elflink.lo In file included from ../../binutils-2.39/bfd/elflink.c:31:0: ../../binutils-2.39/bfd/../include/plugin-api.h:162:2: error: #error "Could not detect architecture endianess" gmake[4]: *** [Makefile:1752: elflink.lo] Error 1 gmake[4]: Leaving directory '/opt/bw/build/binutils-2.39_SunOS5.8_sun4m.001/bfd' gmake[3]: *** [Makefile:1932: all-recursive] Error 1 gmake[3]: Leaving directory '/opt/bw/build/binutils-2.39_SunOS5.8_sun4m.001/bfd' gmake[2]: *** [Makefile:1321: all] Error 2 gmake[2]: Leaving directory '/opt/bw/build/binutils-2.39_SunOS5.8_sun4m.001/bfd' gmake[1]: *** [Makefile:3056: all-bfd] Error 2 gmake[1]: Leaving directory '/opt/bw/build/binutils-2.39_SunOS5.8_sun4m.001' gmake: *** [Makefile:1003: all] Error 2 That
[Bug ld/29843] binutils-2.40 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Nick Clifton --- (In reply to Andreas K. Huettel from comment #11) > Here's a git patch that makes the two tests pass here. > It should also work elsewhere (but of course double-checking is better). It works fine and did not trigger any regressions in my build farm, so I have gone ahead and applied the patch. (To the mainline and the 2.40 branch). Thanks for taking the time to work on this issue. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29843] binutils-2.40 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843 --- Comment #13 from cvs-commit at gcc dot gnu.org --- The binutils-2_40-branch branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f4e184b2747542b123cd06c7f9a4fbaaedc1bbca commit f4e184b2747542b123cd06c7f9a4fbaaedc1bbca Author: Andreas K. Huettel Date: Wed Jan 4 09:31:12 2023 + Fix AArch64 linker testsuite failures triggered by differences in build environments. PR 29843 * testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow for differences in build environments. * testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29843] binutils-2.40 ld test failures "ld-aarch64/tls-relax-gdesc-le-now", "BTI PLT with only GNU PROP"
https://sourceware.org/bugzilla/show_bug.cgi?id=29843 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=502c7218da3c486e58d6ce039b36fb4fa62d3a92 commit 502c7218da3c486e58d6ce039b36fb4fa62d3a92 Author: Andreas K. Huettel Date: Wed Jan 4 09:30:14 2023 + Fix AArch64 linker testsuite failures trigeered by differences in build environments. PR 29843 * testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow for differences in build environments. * testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28909] 2.38 tarball (once again) requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=28909 --- Comment #3 from Tom Vander Aa --- Update... - Touching the .dirstamp seems to do the trick for gas/doc/as.info - But somehow makeinfo is still needed because make wants to build gprofng/doc/gprofng.info. I'll investigate some more and update this bugreport. -- You are receiving this mail because: You are on the CC list for the bug.
