Opened 4 years ago

Closed 3 years ago

Last modified 7 months ago

#62356 closed enhancement (wontfix)

gdb: add arm64 support

Reported by: platipodium (Carsten Lemmen) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.4
Keywords: arm64 upstream Cc: anahata0108, p-bro
Port: gdb

Description

On Big Sur/arm64, installing gdb results in unwanted reinstallation of all dependencies with the +universal variant

 port install gdb
--->  Fetching archive for libiconv
--->  Attempting to fetch libiconv-1.16_1+universal.darwin_20.arm64-x86_64.tbz2.rmd160 from https://mse.uk.packages.macports.org/libiconv
--->  Installing libiconv @1.16_1+universal
--->  Cleaning libiconv
--->  Deactivating libiconv @1.16_1
--->  Cleaning libiconv
--->  Activating libiconv @1.16_1+universal
--->  Cleaning libiconv
--->  Fetching archive for ncurses
--->  Attempting to fetch ncurses-6.2_1+universal.darwin_20.arm64-x86_64.tbz2 from https://mse.uk.packages.macports.org/ncurses

.... and so forth for all dependencies boehmgc, expat, gettext, libiconv, ncurses, zlib

Change History (10)

comment:1 Changed 4 years ago by jmroot (Joshua Root)

Keywords: universal Big Sur removed
Summary: gdb erroneously installs +universal variants of dependenciesgdb: add arm64 support
Type: defectenhancement

This is because gdb sets supported_archs x86_64 i386. On an Apple Silicon system, that means that gdb will be built as x86_64, and thus all dependencies need to be universal.

I'll leave this open as a request to add native arm64 support.

comment:2 Changed 4 years ago by anahata0108

Cc: anahata0108 added

comment:3 Changed 4 years ago by p-bro

Cc: p-bro added

comment:4 Changed 3 years ago by kencu (Ken)

Resolution: wontfix
Status: newclosed

gdb has been fixed by several commits to build the x86_64 version properly on Ventura, including building the x86_64 version transparently on an M1 Mac.

however, gdb upstream does not support arm64 MacOS at present:

<https://inbox.sourceware.org/gdb/1BD161F9-A6BB-4682-AD39-7698D56F0BB0@comcast.net/>

so there is nothing in MacPorts to request, until upstream has something to build.

comment:5 Changed 3 years ago by jmroot (Joshua Root)

Keywords: upstream added

comment:6 in reply to:  4 Changed 15 months ago by barracuda156

Replying to kencu:

gdb has been fixed by several commits to build the x86_64 version properly on Ventura, including building the x86_64 version transparently on an M1 Mac.

however, gdb upstream does not support arm64 MacOS at present:

<https://inbox.sourceware.org/gdb/1BD161F9-A6BB-4682-AD39-7698D56F0BB0@comcast.net/>

so there is nothing in MacPorts to request, until upstream has something to build.

Do we have some alternative, working debugger on aarch64?

comment:7 Changed 15 months ago by kencu (Ken)

lldb works well, fully supported by Apple, current OS support right up the minute.

comment:8 Changed 7 months ago by sectroyer

Herę is repo where you can download gdb compiled for aarch64: https://github.com/SeanMollet/arm-none-eabi-gcc-aarch64-macosx There are also instructions and necessary patches to compile it yourself

comment:9 Changed 7 months ago by platipodium (Carsten Lemmen)

Hmm, I am not experienced with port recipes, but it seems that https://github.com/SeanMollet/arm-none-eabi-gcc-aarch64-macosx provide patch files. So why close this as #wontfix if one could IMHO follow those instructions also in a port recipe: require dependencies, pull gdb source code, pull patches, apply patches, build?

comment:10 Changed 7 months ago by kencu (Ken)

upstream gdb doesn't support arm64 mac yet.

homebrew doesn't have it for arm64 either, naturally

https://github.com/Homebrew/homebrew-core/blob/0b03aa2099819ff1cbda49bbf0426157078f6aed/Formula/g/gdb.rb#L26

Yes -- some guy somewhere put some patches in a personal git repo three years ago and says they make gdb work.

Well -- have at it. That is just not something a project like macports should be hacking into.

Soon enough, I hope, gdb will officially support arm64 macos. Please work on pressuring them, rather than us, as that would be the Right Thing To Do.

Note: See TracTickets for help on using tickets.