Remove devel/arm-elf?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Remove devel/arm-elf?

Christian Weisgerber
Grepping the ports tree for uses of /usr/bin/gcc turned up
devel/arm-elf/gcc.  That port has been marked BROKEN "due to frequent
segfaults during build" for 4.5 years.  I guess nobody has missed
it since.

I was going to suggest that we remove the port, but it's part of
four related ones:

devel/arm-elf/binutils
devel/arm-elf/gcc
devel/arm-elf/gdb
devel/arm-elf/newlib

newlib depends on gcc, so it will have to go too if gcc goes.
binutils and gdb are independent of gcc, and in fact we have packages
for them.  But are they any use on their own?

The ports were imported in 2007, once updated in 2010, the maintainer
asked to be removed in 2012, and otherwise the changes have been
mostly infrastructure churn.

Can we delete all of devel/arm-elf?  Yes?  No?
What's the use of an "arm-elf" cross-tools suite?

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remove devel/arm-elf?

Klemens Nanni-2
On Sun, Aug 18, 2019 at 04:29:03PM +0200, Christian Weisgerber wrote:
> Can we delete all of devel/arm-elf?  Yes?  No?
> What's the use of an "arm-elf" cross-tools suite?
jca wanted to to the same in december 2017 and I had been the only one
replying that I used some of it - but this is long over and I do not use
any that.

https://marc.info/?l=openbsd-ports&m=151319222219915&w=2


Feel free to kill it with OK kn;  I doubt someone will object by now.

Reply | Threaded
Open this post in threaded view
|

Re: Remove devel/arm-elf?

Jonathan Gray-11
In reply to this post by Christian Weisgerber
On Sun, Aug 18, 2019 at 04:29:03PM +0200, Christian Weisgerber wrote:

> Grepping the ports tree for uses of /usr/bin/gcc turned up
> devel/arm-elf/gcc.  That port has been marked BROKEN "due to frequent
> segfaults during build" for 4.5 years.  I guess nobody has missed
> it since.
>
> I was going to suggest that we remove the port, but it's part of
> four related ones:
>
> devel/arm-elf/binutils
> devel/arm-elf/gcc
> devel/arm-elf/gdb
> devel/arm-elf/newlib
>
> newlib depends on gcc, so it will have to go too if gcc goes.
> binutils and gdb are independent of gcc, and in fact we have packages
> for them.  But are they any use on their own?
>
> The ports were imported in 2007, once updated in 2010, the maintainer
> asked to be removed in 2012, and otherwise the changes have been
> mostly infrastructure churn.
>
> Can we delete all of devel/arm-elf?  Yes?  No?

I think they can all be removed.

We have devel/arm-none-eabi and ports clang has support for multiple
targets in a single binary (including arm).

> What's the use of an "arm-elf" cross-tools suite?

I imagine it is for the older abi (aapcs).  The ports were originally
for writing code for microcontrollers but people use eabi with those as
well now.

Reply | Threaded
Open this post in threaded view
|

Re: Remove devel/arm-elf?

Anthony J. Bentley-4
In reply to this post by Christian Weisgerber
Christian Weisgerber writes:

> Grepping the ports tree for uses of /usr/bin/gcc turned up
> devel/arm-elf/gcc.  That port has been marked BROKEN "due to frequent
> segfaults during build" for 4.5 years.  I guess nobody has missed
> it since.
>
> I was going to suggest that we remove the port, but it's part of
> four related ones:
>
> devel/arm-elf/binutils
> devel/arm-elf/gcc
> devel/arm-elf/gdb
> devel/arm-elf/newlib
>
> newlib depends on gcc, so it will have to go too if gcc goes.
> binutils and gdb are independent of gcc, and in fact we have packages
> for them.  But are they any use on their own?
>
> The ports were imported in 2007, once updated in 2010, the maintainer
> asked to be removed in 2012, and otherwise the changes have been
> mostly infrastructure churn.
>
> Can we delete all of devel/arm-elf?  Yes?  No?
> What's the use of an "arm-elf" cross-tools suite?

I used to program Olimex boards with those ports. But that was nearly
ten years ago.

We have many cross-compilers in the tree. It should be easy enough for
someone who needs it to send a diff based on the working ones. A port
broken this long doesn't need to stay.

ok bentley@