Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Won't build on Mac OS X Monterey #181

Closed
huysbs opened this issue May 16, 2022 · 15 comments
Closed

Won't build on Mac OS X Monterey #181

huysbs opened this issue May 16, 2022 · 15 comments

Comments

@huysbs
Copy link

huysbs commented May 16, 2022

Building with:
  Version string:  unknown
  Architecture:    x86_64
  DSP mix:         x86
  RTLSDR support:  yes
  BladeRF support: no
  HackRF support:  no
  LimeSDR support: no
cc  -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION=\"unknown\" -DMODES_DUMP1090_VARIANT=\"dump1090-fa\" -DMISSING_NANOSLEEP -DENABLE_CPUFEATURES -Icpu_features/include -DENABLE_RTLSDR -DSTARCH_MIX_X86 -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -I/usr/local/Cellar/librtlsdr/0.6.0/include/ -I/usr/local/Cellar/libusb/1.0.24/include/libusb-1.0 -c net_io.c -o net_io.o
net_io.c:1086:15: error: implicit declaration of function 'alloca' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    buf = p = alloca(len);
              ^
net_io.c:1086:13: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Werror,-Wint-conversion]
    buf = p = alloca(len);
            ^ ~~~~~~~~~~~
2 errors generated.
make: *** [net_io.o] Error 1
@ChrisDev8
Copy link

Can Confirm. Same Issue.

@ChrisDev8
Copy link

ChrisDev8 commented May 31, 2022

notes | 05/31/22 | 2:26AM | chris-dev
/Users/chris-dev/Documents/dump1090:~$ make

Building with:
Version string: unknown
Architecture: arm64
DSP mix: generic
RTLSDR support: no
BladeRF support: no
HackRF support: no
LimeSDR support: no
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c dump1090.c -o dump1090.o
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c anet.c -o anet.o
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c interactive.c -o interactive.o
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c mode_ac.c -o mode_ac.o
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c mode_s.c -o mode_s.o
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c comm_b.c -o comm_b.o
cc -I. -D_POSIX_C_SOURCE=200112L -DMODES_DUMP1090_VERSION="unknown" -DMODES_DUMP1090_VARIANT="dump1090-fa" -DMISSING_NANOSLEEP -DSTARCH_MIX_GENERIC -O3 -g -std=c11 -fno-common -Wall -Wmissing-declarations -Werror -W -c net_io.c -o net_io.o
net_io.c:1086:15: error: implicit declaration of function 'alloca' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
buf = p = alloca(len);
^
net_io.c:1086:13: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Werror,-Wint-conversion]
buf = p = alloca(len);
^ ~~~~~~~~~~~
2 errors generated.
make: *** [net_io.o] Error 1

@ChrisDev8
Copy link

ChrisDev8 commented Jun 7, 2022

I have integrated your fix to my code and now this happens.
NOTE: buy a macbook with latest update

https://pastebin.com/u5SPbhQr
Password: kpTdPDqtjM

@resuna
Copy link
Member

resuna commented Jun 7, 2022

ld: library not found for -lusb-1.0

Have you installed the M1 version of libusb? What package system are you using to install it?

@ChrisDev8
Copy link

ChrisDev8 commented Jun 7, 2022

I use brew and mac ports all the time!

I've installed on mac ports and brew (also verified)

Screen Shot 2022-06-07 at 7 08 28 PM

I seems like the errors go away if you install them on the same terminal even though I've already installed them.

Also MacOS M1 is different than arm64 on arch / raspberry os

@quochuy
Copy link

quochuy commented Jun 7, 2022

It works on my side (Intel iMac)

@resuna
Copy link
Member

resuna commented Jun 8, 2022

Are you using the native ARM version of libusb? It's actually possible to install and run the intel versions of these package managers on Apple's ARM using Rosetta. Use "file" to check that the actual libraries are arm64 or aarch64 or whatever they call Apple's ARM variant these days. (I think I recall that counterintuitively Apple uses "arm64" and non-Apple 64-bit ARM uses "aarch64" for historical reasons).

I don't have an M1 Mac, but you should see something like this, except with arm64 or aarch64 or something similar instead of x86_64:

[Obsidian:/opt/local/lib] peter% file *
...
libusb.1.dylib:            Mach-O 64-bit dynamically linked shared library x86_64
libusb.dylib:              Mach-O 64-bit dynamically linked shared library x86_64
...

@ChrisDev8
Copy link

ChrisDev8 commented Jun 8, 2022

That's because you have a x64 architecture, in 2020 Apple released their M1 MacBooks which ran on arm64 architecture instead of amd64 or x64. I thought is was a developers job to make their software usable on all platforms. Also M1 MacBooks are 100% different that Arch Linux, Raspberry Pi, and Intel Macs

@mutability
Copy link

Please try #185 for the alloca etc compile failures.

For the M1 build problem, please create a separate issue. I don't have a M1 build environment (and it's not a target we automatically build for) so it's likely that you'll need to work out the underlying problem yourself and provide a PR (either build changes, if needed, or doc updates to describe what's needed in the build environment)

@sdlyyxy
Copy link

sdlyyxy commented Jun 9, 2022

@ChrisDev8 Check if there is a libusb-1.0.0.dylib at /opt/homebrew/lib, then try LDFLAGS="-L/opt/homebrew/lib" make.

@resuna
Copy link
Member

resuna commented Jun 10, 2022

That's why I'm asking you to check that the libusb you're using has the right architecture. The linker is either not finding it or there's something wrong with it.

In an attempt to diagnose the problem, could you locate the libusb.dylib on your system, and use the file command as I demonstrated to determine what architecture it is.

@ChrisDev8
Copy link

I can confirm there is a libusb-1.0.0.dylib at /opt/homebrew/lib

Screen Shot 2022-06-12 at 6 17 37 PM

I entered file libusb-1.0.0.dylib

and it returned..
libusb-1.0.0.dylib:

Mach-O 64-bit dynamically linked shared library arm64

Screen Shot 2022-06-12 at 6 22 03 PM

@ChrisDev8
Copy link

I tried those pull request and now getting this error.

Building with:
  Version string:  unknown
  Architecture:    arm64
  DSP mix:         generic
  RTLSDR support:  yes
  BladeRF support: yes
  HackRF support:  yes
  LimeSDR support: no
cc -g -o dump1090 dump1090.o anet.o interactive.o mode_ac.o mode_s.o comm_b.o net_io.o crc.o demod_2400.o stats.o cpr.o icao_filter.o track.o util.o convert.o ais_charset.o adaptive.o cpu.o sdr.o fifo.o sdr_ifile.o dsp/helpers/tables.o sdr_rtlsdr.o sdr_bladerf.o sdr_hackrf.o compat/clock_nanosleep/clock_nanosleep.o dsp/generated/flavor.generic.o dsp/generated/dispatcher.o  -lpthread -lm -L/opt/homebrew/Cellar/librtlsdr/0.6.0/lib -lrtlsdr -lusb-1.0 -L/opt/homebrew/Cellar/libbladerf/2021.10/lib/ -lbladeRF -L/opt/homebrew/Cellar/hackrf/2021.03.1/lib -lhackrf -lncurses
ld: library not found for -lusb-1.0
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [dump1090] Error 1

I Used make -v and i get this:

GNU Make 3.81
Copyright (C) 2006  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.

This program built for i386-apple-darwin11.3.0

It's a compatibility error

@mutability
Copy link

Please create a separate issue for your build problems, and be sure to include the command line you are using when trying to build -- I note that you still don't have the right library path in your LDFLAGS.

@mutability
Copy link

Original issue is fixed on the dev branch, closing this.

sdlyyxy added a commit to sdlyyxy/dump1090-fa that referenced this issue Aug 16, 2022
Some versions of librtlsdr (including the version installed by Homebrew
bottle) wrongly declare -lusb-1.0 in its pkg-config file's Libs section.
On Apple Silicon Macs, Homebrew installs libusb dylibs in /opt/homebrew/lib,
which is not a known path for linkers and causes build failure. Some people
reported this linker problem in flightaware#166, flightaware#181. This should fix it.

For the redundant -lusb-1.0 problem, also see:
https://gitea.osmocom.org/sdr/rtl-sdr/commit/222517b506278178ab93182d79ccf7eb04d107ce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants