Building on Mac M1

Not an issue but perhaps worth noting the following issues and adding to the documentation?

Homebrew on macOS now installs into /opt/homebrew/ so you need to adjust paths inn the Makefile appropriately.
If you have installed binutils with Homebrew, this will not build on M1 without deactivating them.

So need to (1) edit the Makefile:85 to

 ifdef OSX
    INCLUDE_PATHS += -I/opt/homebrew/include/libusb-1.0
    LDLIBS = -L. -L/opt/homebrew/lib -lusb-1.0 -ldl -lncurses -lpthread -lintl -L$(OLOC) -l$(ORBLIB)

and (2) need to (at least temporarily) move aside any binutils installed in /opt/homebrew/opt/binutils
mv /opt/homebrew/opt/binutils ~/binutils

John, Thanks for this...really useful to know that it builds on OSX-M1 with minimal tweaks. Would you happen to know if there's an environment variable we can use to guard this difference so at least the majority of it is dealt with automatically? Obviously we can't go moving entire subsystems around via the makefile but we should be able to get the config right.... Dave

…

On Fri, 24 Jun 2022, 18:50 John, ***@***.***> wrote: Not an issue but perhaps worth noting the following issues and adding to the documentation? 1. Homebrew on macOS now installs into /opt/homebrew/ so you need to adjust paths inn the Makefile appropriately. 2. If you have installed binutils with Homebrew, this will *not* build on M1 without deactivating them. So need to (1) edit the Makefile:85 to ifdef OSX INCLUDE_PATHS += -I/opt/homebrew/include/libusb-1.0 LDLIBS = -L. -L/opt/homebrew/lib -lusb-1.0 -ldl -lncurses -lpthread -lintl -L$(OLOC) -l$(ORBLIB) and (2) need to (at least temporarily) move aside any binutils installed in /opt/homebrew/opt/binutils mv /opt/homebrew/opt/binutils ~/binutils — Reply to this email directly, view it on GitHub <#63>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJTBD5DU5BFUJC5FU3HSN3VQXYNHANCNFSM5ZYRTOLA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

On x86 macOS with Homebrew, the libusb paths can be found through pkg-config, so I would assume the same is the case for ARM macOS, which would eliminate the need to hardcode paths.

Can you elaborate on the binutils issue?

`% pkg-config --cflags --libs libusb -I/opt/homebrew/Cellar/libusb-compat/0.1.5_1/include -I/opt/homebrew/Cellar/libusb/1.0.26/include/libusb-1.0 -L/opt/homebrew/Cellar/libusb-compat/0.1.5_1/lib -lusb` And the Homebrew prefix is available as an environmental variable. `% echo $HOMEBREW_PREFIX /opt/homebrew` I had binutils installed as a Homebrew package - I needed it on x86 because of this #23 and I must have reinstalled it on my M1. It is also a requirement listed in the OS X install instructions as mentioned by @frantthetank who suggests this is necessary - which is indeed the case on x86 builds. `export LDFLAGS="-L/usr/local/opt/binutils/lib" export CPPFLAGS="-I/usr/local/opt/binutils/include”` But this doesn’t work on M1 ` Compiling Src/nwclient.c ld: warning: directory not found for option '-L/usr/local/opt/binutils/lib' ld: warning: ignoring file ofiles/liborb.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 ) Undefined symbols for architecture arm64: "_TPIUDecoderInit", referenced from: _main in orbuculum.o "_TPIUGetPacket", referenced from: __stripTPIU in orbuculum.o "_TPIUPump", referenced from: __stripTPIU in orbuculum.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:233: orbuculum] Error 1 This program has absolutely no warranty.` On M1 you need the Apple provided binutils in the Command Line tools. So I moved the Homebrew installed binutils to expose the Apple command line tools and we are in business but all I think you need do is NOT export the LDFLAGS/CPPFLAGS. `mv /opt/homebrew/opt/binutils ~/binutils % $(which ranlib) -V Apple Inc. version cctools-977.1 error: /Library/Developer/CommandLineTools/usr/bin/ranlib: no archives specified Usage: /Library/Developer/CommandLineTools/usr/bin/ranlib [-sactfqLT] [-] archive […] make clean && make Compiling Src/generics.c Compiling Src/itmDecoder.c Compiling Src/tpiuDecoder.c Compiling Src/msgDecoder.c Compiling Src/msgSeq.c Compiling Src/etmDecoder.c Completed build of orb Compiling Src/orbuculum.c Src/orbuculum.c:1063:5: warning: 'sem_init' is deprecated [-Wdeprecated-declarations] sem_init( &_r.dataForClients, 0, 0 ); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/semaphore.h:55:42: note: 'sem_init' has been explicitly marked deprecated here int sem_init(sem_t *, int, unsigned int) __deprecated; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:204:40: note: expanded from macro '__deprecated' #define __deprecated __attribute__((__deprecated__)) ^ 1 warning generated. Compiling Src/nwclient.c Completed build of orbuculum Compiling Src/orbfifo.c Compiling Src/filewriter.c Compiling Src/itmfifos.c Completed build of orbfifo Compiling Src/orbcat.c Completed build of orbcat Compiling Src/orbtop.c Compiling Src/symbols.c Compiling Src/external/cJSON.c Completed build of orbtop Compiling Src/orbdump.c Completed build of orbdump Compiling Src/orbmortem.c Compiling Src/sio.c Completed build of orbmortem Compiling Src/orbprofile.c Compiling Src/ext_fileformats.c Completed build of orbprofile Compiling Src/orbtrace.c Compiling Src/orbtraceIf.c Completed build of orbtrace Compiling Src/orbstat.c Completed build of orbstat` Hope that clarifies things!

…

On 24 Jun 2022, at 22:47, zyp ***@***.***> wrote: On x86 macOS with Homebrew, the libusb paths can be found through pkg-config, so I would assume the same is the case for ARM macOS, which would eliminate the need to hardcode paths. Can you elaborate on the binutils issue? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

Hi John, I've included a note in the readme in commit 5da8258 which references this discussion for when someone else gets banged by it. Thanks for taking the time to report it!

DAVE

Navigation Menu

Repository navigation

Building on Mac M1 #63

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Building on Mac M1 #63

Description

Activity

mubes commented on Jun 24, 2022

zyp commented on Jun 24, 2022

Gasman2014 commented on Jun 25, 2022

mubes commented on Jun 25, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions