devel/arm-none-eabi: update to binutils 2.40 and gcc 12.2.0

flavor? +@pkgpath devel/${CONFIG}/gcc, I assume this will need a pkg_add quirk to move from gcc-linaro to gcc? Cheers, Patrick diff --git a/devel/arm-none-eabi/Makefile b/devel/arm-none-eabi/Makefile index 6dc255ac18a..6b2a345ca9f 100644 --- a/devel/arm-none-eabi/Makefile +++ b/devel/arm-none

Update devel/arm-none-eabi/binutils

=== RCS file: /cvs/ports/devel/arm-none-eabi/binutils/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile11 Mar 2022 18:49:35 - 1.8 +++ Makefile3 Mar 2023 11:24:25 - @@ -1,6 +1,6 @@ COMMENT= binutils for ${CONFIG} cross-development -VERSION

Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0

-mfpu=fpv4-sp-d16 > > On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match > for > them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'. > > Is there a way to update the port on my system to include this multilib > flavor? The a

Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0

oat-abi=hard -mfpu=fpv4-sp-d16 > > On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match > for > them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'. > > Is there a way to update the port on my system to include this multil

Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0

oat-abi=hard -mfpu=fpv4-sp-d16 > > On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match > for > them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'. > > Is there a way to update the port on my system to include this multil

Re: CONFIGURE_STYLE=none

On 2022/11/13 17:53, Christian Weisgerber wrote: > We have a number of ports that set CONFIGURE_STYLE=none. On its own, > that doesn't mean anything. "none" is not a defined CONFIGURE_STYLE. > If a port should not attempt to run a configure script, simply don't > set

Re: CONFIGURE_STYLE=none

On Sun, Nov 13, 2022 at 05:53:41PM +0100, Christian Weisgerber wrote: > We have a number of ports that set CONFIGURE_STYLE=none. On its own, > that doesn't mean anything. "none" is not a defined CONFIGURE_STYLE. > If a port should not attempt to run a configure script,

CONFIGURE_STYLE=none

We have a number of ports that set CONFIGURE_STYLE=none. On its own, that doesn't mean anything. "none" is not a defined CONFIGURE_STYLE. If a port should not attempt to run a configure script, simply don't set CONFIGURE_STYLE at all. That said, both the perl and python m

Re: [Update] devel/arm-none-eabi 7.4.1 -> 7.5.0

Somebody claiming to be Tracey Emery wrote: > Hello ports, > > I'm not sure anyone is particularly interested in this but me, and the > patch is pretty gross and a significant change, so I'm sure it'll take > awhile before anyone really wants to review this. I have a version o

Re: Update arm-none-eabi binutils to 2.31.1

2.31. Given that there is a 2.31.1 I updated to that one. > > ok? The existing targets which default to both are arm64 xen and tegra. building the xenguest_arm64 target with binutils 2.30 LD u-boot aarch64-none-elf-ld.bfd: arch/arm/cpu/armv8/start.o: relocation R_AARC

Update arm-none-eabi binutils to 2.31.1

U-Boot targets that use the CONFIG_POSITION_INDEPENDENT and CONFIG_LINUX_KERNEL_IMAGE_HEADER options don't build because they generate a relocation that binutils 2.30 doesn't like. This is fixed in binutils 2.31. Given that there is a 2.31.1 I updated to that one. ok? Index: devel/arm-none

arm-none-eabi-*: Support for Cortex-M33

Updates to the arm-none-eabi tools to get support for Cortex-M33 MCUs: 1. Update binutils to 2.30 to get a version that knows about the Cortex-M33 2. Update newlib to 3.3.0 to get a version that knows about the ARMv8-M architecture family 3. Request the R/M profile multilib configuration

Re: arm-none-eabi-{gcc-linaro,newlib}: Add 'rmprofile' flavor

library, for example MMDVM_HS (https://github.com/juribeparada/MMDVM_HS). Is this difficult to add into devel/arm-none-eabi/newlib? Regards, -- SASANO Takayoshi (JG1UAA)

arm-none-eabi-{gcc-linaro,newlib}: Add 'rmprofile' flavor

not being a full thumb-2 implementation. This fixes the issue reported a couple months ago with division on the Cortex-M0 using non-thumb code from libgcc, and also fixes link errors when using Cortex-M4 floating point code. It may be appropriate to just change the base arm-none-eabi configuration

arm-none-eabi-gcc-linaro-6.3.2017.02p3: incorrect libgcc linking

Hello, I use arm-none-eabi-gcc-linaro-6.3.2017.02p3 to write a code for Cortex-M0 SoC, which uses only Thumb instruction. I found that arm-none-eabi-gcc with -mcpu=cortex-m0 option links ARM-instruction library when a compiled code has division/remainder operation. Here is a code for testing

Re: i386 & armv7 unbroken on arm-none-eabi/gcc-linaro

On Sat, Sep 22, 2018 at 07:34:46PM -0400, Gregory Czerniak wrote: > In an attempt to diagnose and fix the problem, I recently commented out > the i386 and armv7 BROKEN tags from the arm-none-eabi/gcc-linaro port > on my local machines running relatively close to -current. Neither >

i386 & armv7 unbroken on arm-none-eabi/gcc-linaro

In an attempt to diagnose and fix the problem, I recently commented out the i386 and armv7 BROKEN tags from the arm-none-eabi/gcc-linaro port on my local machines running relatively close to -current. Neither architecture seems to have a problem compiling this port anymore. Looking

Re: none

Pavel Korovin(p...@tristero.se) on 2018.04.25 22:23:37 +0300: > Sebastian, thank you! > OK for me with Jeremie's corrections. > Though I'd postpone commiting it to 5.6.4: hopefully I'll finish updating > ELK stack to 6.2.4 before the weekend and include it there, OK? yes, thats fine. just put it

Re: none

Sebastian, thank you! OK for me with Jeremie's corrections. Though I'd postpone commiting it to 5.6.4: hopefully I'll finish updating ELK stack to 6.2.4 before the weekend and include it there, OK? -- With best regards, Pavel Korovin On 04/25, Jeremie Courreges-Anglas wrote: > On Wed, Apr 25

update devel/arm-none-eabi/gcc-linaro to 7.2-2017.11

=== RCS file: /cvs/ports/devel/arm-none-eabi/gcc-linaro/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile29 Nov 2017 11:58:44 - 1.13 +++ Makefile8 Apr 2018 08:46:42 - @@ -7,9 +7,8 @@ BROKEN-armv7= error

Re: devel/arm-none-eabi/gcc-linaro,aarch64 failure (clang fallout?)

On Thu, Aug 03, 2017 at 11:06:56PM -0700, Nick Owens wrote: > hi, i tried to build the aarch64 flavor of u-boot to play around with > my new pinebook (pine64-based laptop). > > unfortunately gcc-linaro fails with the following: > > /usr/ports/pobj/aarch64-none-elf-gcc-linaro-6

devel/arm-none-eabi/gcc-linaro,aarch64 failure (clang fallout?)

hi, i tried to build the aarch64 flavor of u-boot to play around with my new pinebook (pine64-based laptop). unfortunately gcc-linaro fails with the following: /usr/ports/pobj/aarch64-none-elf-gcc-linaro-6.3.2017.02-aarch64/gcc-linaro-6.3-2017.02/gcc/config/aarch64/aarch64.md:801:10873: fatal

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

On 2016/12/06 09:48, Stuart Henderson wrote: > Since this changes the pkgpath, dependencies need a bump to chase it - > you're already bumping the various devel/arm-none-eabi so... > > sqlite> select * from depends where dependspath like 'devel/arm-none-eabi%' >...> and

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

On 2016/12/06 16:27, Patrick Wildt wrote: > > zhuk@ gave me some of those pointers as well last night. I also added > the @pkgpath, though he said I should explicitly add the trailing comma. The trailing comma looks odd to me, though I don't think it matters either way, we have it both ways in

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

it via @pkgpath. It's a little more work > but I think it's a more standard way to handle it. > > You can do this by adding "@pkgpath devel/arm-none-eabi/binutils" and > "@pkgpath devel/arm-none-eabi/gcc-linaro" to the various PFRAG.arm files, > remove the -Dar

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

. You can do this by adding "@pkgpath devel/arm-none-eabi/binutils" and "@pkgpath devel/arm-none-eabi/gcc-linaro" to the various PFRAG.arm files, remove the -Darm / -Daarch64 workaround, and I think also guard against someone trying FLAVOR="aarch64 arm", e.g

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

a copy of the > > devel/arm-none-eabi toolchain with a different --target and without > > gdb/newlib (+ one source code patch in gcc-linaro for aarch64, > > patch-gcc_config_aarch64_geniterators_sh). > > > > Snippet from the DESCRs: > > > > binutils >

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

a copy of the > > devel/arm-none-eabi toolchain with a different --target and without > > gdb/newlib (+ one source code patch in gcc-linaro for aarch64, > > patch-gcc_config_aarch64_geniterators_sh). > > > > Snippet from the DESCRs: > > > > binutils >

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

On Fri, Nov 25, 2016 at 10:54:57AM +0100, Patrick Wildt wrote: > Hi, > > I would like to import two ports that will allow the cross-build of > u-boot for 64-bit ARM machines. This is basically a copy of the > devel/arm-none-eabi toolchain with a different --target and without >

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

On Fri, Nov 25, 2016 at 10:54:57AM +0100, Patrick Wildt wrote: > Hi, > > I would like to import two ports that will allow the cross-build of > u-boot for 64-bit ARM machines. This is basically a copy of the > devel/arm-none-eabi toolchain with a different --target and without >

[NEW] devel/aarch64-none-elf with binutils and gcc

Hi, I would like to import two ports that will allow the cross-build of u-boot for 64-bit ARM machines. This is basically a copy of the devel/arm-none-eabi toolchain with a different --target and without gdb/newlib (+ one source code patch in gcc-linaro for aarch64, patch

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

On Thu, Jan 14, 2016 at 11:15:14AM -0200, Daniel Bolgheroni wrote: > Anyway, here is an updated diff for review, with the hope I didn't > forget any of the inputs received. Any more inputs on this diff? BTW, thank you for the feedbacks received so far. -- db

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

On Tue, Jan 12, 2016 at 03:05:05PM +, Brandon Mercer wrote: > I'm somehow missing the initial email that Daniel wrote that proposes > building libstdc++ as part of arm-none-eabi, however, that bit me while > working on some stuff last week. I think the toolchain is not very useful

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

On 2016/01/13 10:15, Daniel Bolgheroni wrote: > On Tue, Jan 12, 2016 at 03:05:05PM +, Brandon Mercer wrote: > > I'm somehow missing the initial email that Daniel wrote that proposes > > building libstdc++ as part of arm-none-eabi, however, that bit me while > > working on

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

On Wed, Jan 13, 2016 at 03:15:32PM -0500, Dave Vandervies wrote: > Would making gcc-linaro-bootstrap a FLAVOR of gcc-linaro, and therefore > keeping the patches and the configuration for the bootstrap compiler in > the same place as for the main one, be feasible? > (The build process would then

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

Somebody claiming to be Brandon Mercer wrote: > On Sat, Jan 9, 2016 at 4:21 PM Dave Vandervies wrote: > > One issue with separating out the bootstrap compiler (that's quite > > relevant on ARM, but I don't know enough about AVR32 to comment there) > > is that the newlib build

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

On Wed, Jan 13, 2016 at 4:01 PM Daniel Bolgheroni wrote: > On Wed, Jan 13, 2016 at 03:15:32PM -0500, Dave Vandervies wrote: > > Would making gcc-linaro-bootstrap a FLAVOR of gcc-linaro, and therefore > > keeping the patches and the configuration for the bootstrap compiler

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

On Sat, Jan 9, 2016 at 4:21 PM Dave Vandervies <dj3va...@terse.ca> wrote: > Somebody claiming to be Daniel Bolgheroni wrote: > > Here I propose the build of libstdc++-v3 as part of devel/arm-none-eabi. > > Some ports do build it (e.g. devel/avr32), while others don't (e

Re: Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

Somebody claiming to be Daniel Bolgheroni wrote: > Here I propose the build of libstdc++-v3 as part of devel/arm-none-eabi. > Some ports do build it (e.g. devel/avr32), while others don't (e.g. > devel/arm-elf). (The main reason arm-none-eabi doesn't build it is because I use

Proposed change to build libstdc++-v3 as part of devel/arm-none-eabi

Here I propose the build of libstdc++-v3 as part of devel/arm-none-eabi. Some ports do build it (e.g. devel/avr32), while others don't (e.g. devel/arm-elf). The reason for this is to be able to build binaries for boards like Leaflabs Maple Mini (and many others), based on ARM Cortex-M3/M4, using

Re: devel/arm-none-eabi/newlib is broken

On 2015-07-13, Dave Vandervies dj3va...@terse.ca wrote: I went with the bigger hammer to make sure all of the configure overrides would get through and not just the one that was observed causing problems when it got lost. I agree. Also, check how many config.guess files are hiding in

Re: devel/arm-none-eabi/newlib is broken

Shall I commit the previous big hammer fix then? On Tue, Jul 14, 2015, 15:46 Christian Weisgerber na...@mips.inka.de wrote: On 2015-07-13, Dave Vandervies dj3va...@terse.ca wrote: I went with the bigger hammer to make sure all of the configure overrides would get through and not just the

Re: devel/arm-none-eabi/newlib is broken

scaffolding to prevent autoconf from picking them up, but the arm-none-eabi ports are too complex for the normal things to work. ...And, after following up on the suggestions from this thread and digging around in /usr/ports/infrastructure, I think I've figured out one of the reasons why and come

Re: devel/arm-none-eabi/newlib is broken

side of that tradeoff is the correct one to take. Index: Makefile === RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 Makefile --- Makefile 28 May 2015 23:28:26

Re: devel/arm-none-eabi/newlib is broken

Index: Makefile === RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile 28 May 2015 23:28:26 - 1.1.1.1 +++ Makefile 12 Jul

Re: devel/arm-none-eabi/newlib is broken

On 2015-07-12, Dave Vandervies dj3va...@terse.ca wrote: In case anyone is interested, devel/arm-none-eabi/newlib broke in my bulk because gmkdir was detected at configure time (and junked by dpb later on). Quick fix: Make coreutils an explicit build dependency so dpb knows something

Re: devel/arm-none-eabi/newlib is broken

On 07/12/15 13:27, Antoine Jacoutot wrote: In case anyone is interested, devel/arm-none-eabi/newlib broke in my bulk because gmkdir was detected at configure time (and junked by dpb later on). ... checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p ... Making install

Re: devel/arm-none-eabi/newlib is broken

Somebody claiming to be Antoine Jacoutot wrote: In case anyone is interested, devel/arm-none-eabi/newlib broke in my bulk because gmkdir was detected at configure time (and junked by dpb later on). Quick fix: Make coreutils an explicit build dependency so dpb knows something is using it. I

Re: devel/arm-none-eabi/newlib is broken

On Sun, Jul 12, 2015 at 11:11:09PM +0100, Nigel Taylor wrote: On 07/12/15 13:27, Antoine Jacoutot wrote: In case anyone is interested, devel/arm-none-eabi/newlib broke in my bulk because gmkdir was detected at configure time (and junked by dpb later on). ... checking for a thread-safe

Re: devel/arm-none-eabi/newlib is broken

On 2015/07/12 16:09, Dave Vandervies wrote: Somebody claiming to be Antoine Jacoutot wrote: In case anyone is interested, devel/arm-none-eabi/newlib broke in my bulk because gmkdir was detected at configure time (and junked by dpb later on). Quick fix: Make coreutils an explicit build

Re: devel/arm-none-eabi/newlib is broken

On 07/13/15 00:54, Dave Vandervies wrote: Somebody claiming to be Stuart Henderson wrote: For some common things (in particular programs from coreutils) we have scaffolding to prevent autoconf from picking them up, but the arm-none-eabi ports are too complex

Re: devel/arm-none-eabi/newlib is broken

Somebody claiming to be Stuart Henderson wrote: For some common things (in particular programs from coreutils) we have scaffolding to prevent autoconf from picking them up, but the arm-none-eabi ports are too complex for the normal things to work

devel/arm-none-eabi/newlib is broken

In case anyone is interested, devel/arm-none-eabi/newlib broke in my bulk because gmkdir was detected at configure time (and junked by dpb later on). ... checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p ... Making install in . gmake[3]: Entering directory '/exopi-obj/pobj/arm

Re: first draft: arm-none-eabi-gcc

On Thu, 21 May 2015 09:50:21 -0400 Dave Vandervies wrote: One question, why the linaro gcc and not https://launchpad.net/gcc-arm-embedded ? Linaro is the variant preferred by the embedded devs I'm working with, so in the absence of a good reason to do otherwise I went with the path of

Re: first draft: arm-none-eabi-gcc

On Thu, 21 May 2015, Dave Vandervies wrote: Somebody claiming to be Damien Miller wrote: One question, why the linaro gcc and not https://launchpad.net/gcc-arm-embedded ? Linaro is the variant preferred by the embedded devs I'm working with, so in the absence of a good reason to do

Re: first draft: arm-none-eabi-gcc

On Wed, 20 May 2015, Dave Vandervies wrote: GCC configured as a cross-compiler for arm-none-eabi for embedded development, accompanied by binutils, gdb, and newlib. This is based on the old (gcc 4.4) arm-elf port, with the versions of the tools brought up to date and a GCC option parsing bug

Re: first draft: arm-none-eabi-gcc

Somebody claiming to be Damien Miller wrote: One question, why the linaro gcc and not https://launchpad.net/gcc-arm-embedded ? Linaro is the variant preferred by the embedded devs I'm working with, so in the absence of a good reason to do otherwise I went with the path of least resistance. --

Re: first draft: arm-none-eabi-gcc

On Thu, May 21, 2015 at 5:38 AM Damien Miller d...@mindrot.org wrote: On Wed, 20 May 2015, Dave Vandervies wrote: GCC configured as a cross-compiler for arm-none-eabi for embedded development, accompanied by binutils, gdb, and newlib. This is based on the old (gcc 4.4) arm-elf port

first draft: arm-none-eabi-gcc

GCC configured as a cross-compiler for arm-none-eabi for embedded development, accompanied by binutils, gdb, and newlib. This is based on the old (gcc 4.4) arm-elf port, with the versions of the tools brought up to date and a GCC option parsing bug that caused random crashes during build fixed

Re: Port of arm-none-eabi-gcc

On Mon, Jan 28, 2013 at 09:34:08PM -0600, Maximo Pech wrote: [...] I don't mind porting it myself, but I'd like to have feedback from you first, to avoid duplicate work and also for some hints you may have. [...] I have a port for arm-none-eabi in my portstree. I basically copied the arm-elf

Port of arm-none-eabi-gcc

Hi guys, looking at the ports tree I see that arm-none-eabi-gcc is not available. I don't mind porting it myself, but I'd like to have feedback from you first, to avoid duplicate work and also for some hints you may have. There is arm-elf-gcc or somehing like that and I'm thinking that it could