I'm trying to build an OS Image for Raspberry pi on MacOS.
make failed because gcc is missing so I installed it with homebrew.
Still I cannot build the image due to the same error:
% make raspberrypi0w_defconfig
...
% make menuconfig
...
% brew install gcc
...
% brew list --versions gcc
gcc 11.3.0_2
% gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include- dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% make
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
You must install 'gcc' on your build machine
make: *** [dependencies] Error 1
Tried a make clean but I'm still getting the same error...
I ended up switching to gcc (it was a path issue).
clang is apple's C compiler, and when you type gcc, this is the compiler that is used by default. When you install gnu c, (using homebrew in my case), you still need to put it ahead of clang in the path.
However, using BuildRoot on MacOS ended up being a rabbit hole.
There are instructions here: https://github.com/generia/buildroot-osx
, but for me it was far simpler to setup an ubuntu VM and build on it. Which I did.
Related
Note: This problem, which I have already solved, is a very different problem from every other similar question on Stack Overflow. I have posted this question and answer in the hopes that it will help someone else experiencing the same issue (or so that, when I have this problem again in 3 years, I'll find this answer).
I am running VirtualBox 6.1.26 on macOS Catalina 10.15.7. I am emulating centOS 7:
$ uname -r
3.10.0-1160.36.2.el7.x86_64
I "inserted" the VirtualBox Guest Additions CD and followed the auto-run prompts to install the Guest Additions. Part way through, it aborted, saying:
This system is currently not set up to build kernel modules.
Please install the gcc make perl packages from your distribution.
Note that I have gcc, make, perl, kernel-devel, and kernel-headers all installed. It also prompted me to check the file /var/log/vboxadd-setup.log for more details. The contents of that log were interesting:
Building the main Guest Additions 6.1.26 module for kernel 3.10.0-1160.36.2.el7.x86_64.
Error building the module. Build output follows.
make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/3.10.0-1160.36.2.el7.x86_64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j4 modules
arch/x86/Makefile:96: stack-protector enabled but compiler support broken
arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y, but not supported by the compiler. Compiler update recommended.. Stop.
make: *** [vboxguest] Error 2
modprobe vboxguest failed
Extensive searching for these errors yields multiple forum posts and Stack Overflow questions whose replies and accepted answers reveal either that I'm missing one of those installed packages (I'm not) or that my GCC version is less than 7.3 (when support for CONFIG_RETPOLINE=y was added). However:
$ gcc --version
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
This is > 7.3, so it does support this feature. I should note that I installed GCC using the Yum devtoolset packages in order to use this newer compiler:
$ sudo yum list installed|grep devtoolset
...
devtoolset-8-gcc.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-c++.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-gdb-plugin.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
...
devtoolset-8-make.x86_64 1:4.2.1-4.el7 #centos-sclo-rh
...
And I do not have any other GCC versions installed:
$ sudo yum list installed|grep gcc
devtoolset-8-gcc.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-c++.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
devtoolset-8-gcc-gdb-plugin.x86_64 8.3.1-3.2-el7 #centos-sclo-rh
libgcc.x86_64 4.8.5-44.el7 #anaconda
And I have this in ~/.bashrc to enable devtoolset upon login:
...
source scl_source enable devtoolset-8
...
What am I doing wrong?
It turned out the problem wasn't that I was using the wrong GCC version (not possible) or that I was missing any installed packages (I wasn't). Instead, it was a consequence of how the VirtualBox Guest Additions "auto-run" works. Something about the way it runs results in a "fresh" environment without devtoolset-8 properly sourced. As a result, it cannot find the installed GCC 8.3.
The solution was simple: When the auto-run prompt appeared, I dismissed it and did not run auto-run. Instead, I opened a fresh Terminal window and changed directories to /run/media/[username]/VBox_GAs_6.1.26 (YMMV on the exact location of the mounted disk), then ran this command:
$ sudo ./VBoxLinuxAdditions.run
That command completed successfully, the kernel module compiled, the Guest Additions installed, and they are working properly now.
I have a C++ application that uses WxWidgets. It compiles perfectly with g++ on my computer.
However I need to run the application on a Raspberry Pi 3. Compiling directly on Raspi takes almost an hour.
So I want to do a cross compilation: compile it on my computer and copy the executable to raspberry.
I tried to follow a tutorial, however the generated file is an "x86-64" file:
http://yasriady.blogspot.com/2015/10/how-to-build-wxwidgets-for-raspberry-pi.html
My computer:
Ubuntu 20.04.2 LTS;
g++ 9.3.0;
wxWidgets v3.1.5.0;
build flags for my computer: CC_FLAGS=-std=c++17 -w -c -rdynamic -W wx-config --cxxflags --libs --gl-libs geos-config --cflags -lgeos -lglut -lGLU -lGL -lm -lGLEW .
Should I re-install wxWidgets for arm? I'm new to cross-compilation
Thank you so much
I already have wxWidgets installed and compiling for x86. Afterwards, I installed wxWidgets for arm-linux following the tutorial.
When I run "make for the examples from the samples folder, the generated file is for x86.
Maybe "make" is compiling using the x86 compiler, not the newly installed arm compiler.
You should be able to cross-compile for RPi without any problems, double check that you've specified the correct --host option and didn't get any errors from configure (if you did, look at config.log to see why).
I installed LLVM on OS X with brew by brew install llvm and I tested it with hello.c with llvm-gcc, and it generates the IR for me. However, when I want to execute the IR code with lli hello.ll or compile it to assembler by llc hello.ll, clang hello.s -x assembler -o hello and run it with ./hello. I got -bash: lli: command not found error. So I tried to add the class path as: export CLASSPATH="/usr/local/Cellar/llvm/3.6.2/bin/lli:$CLASSPATH". However, I still didn't add the class path successfully. Anyone has ideas?
As discussed in the comment, the actual path where executables located is in opt. So export PATH="/usr/local/opt/llvm/bin:$PATH" should set the environment variables for llvm.
First of all, I know there are similar questions but I'm having no luck, so decided to ask a new one myself.
I'm trying to brew install the 64-bit version pjsip, but I always end up with the i386 version.
I've seen people whose brew --env yields CFLAGS and CXXFLAGS, but for some reason, mine doesn't, so I have no clue where to set the correct architecture.
$ brew --env
HOMEBREW_CC: clang
HOMEBREW_CXX: clang++
MAKEFLAGS: -j2
CMAKE_PREFIX_PATH: /usr/local
CMAKE_INCLUDE_PATH: /usr/include/libxml2:/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
CMAKE_LIBRARY_PATH: /System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries
PKG_CONFIG_LIBDIR: /usr/lib/pkgconfig:/usr/local/Library/ENV/pkgconfig/10.9
ACLOCAL_PATH: /usr/local/share/aclocal
PATH: /usr/local/Library/ENV/4.3:/usr/bin:/bin:/usr/sbin:/sbin
$ brew --config
HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/mxcl/homebrew
HEAD: 8c19edbdd364200fb2cc9276b0bc49ec4cb98aae
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: dual-core 64-bit penryn
OS X: 10.9-x86_64
Xcode: 5.0.1
CLT: 5.0.1.0.1.1382131676
GCC-4.0: build 5494
Clang: 5.0 build 500
X11: 2.7.4 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /Library/Frameworks/Python.framework/Versions/2.7/bin/python => /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
I've seen people referring to the version of ruby and I'm not sure it matters, but mine is a Universal build:
$ file /usr/bin/ruby
/usr/bin/ruby: Mach-O universal binary with 2 architectures
/usr/bin/ruby (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/ruby (for architecture i386): Mach-O executable i386
brew install -v pjsip shows:
==> ./configure --prefix=/usr/local/Cellar/pjsip/2.1
checking build system type... i386-apple-darwin13.0.0
checking host system type... i386-apple-darwin13.0.0
checking target system type... i386-apple-darwin13.0.0
Somehow it thinks that we're on a 64bit system, which is odd, as I'm definitely running a 64bit OS. Checking through the arch-host-OS detection code shows that is uses arch to determine the architecture. For some odd reason, this is reporting that we're a 32bit system:
$ arch
i386
While under linux:
$ arch
x86_64
The quick solution is to do a brew edit pjsip, and change line 22 to read:
system "./configure", "--prefix=#{prefix}", "--host=x86_64-apple-darwin13.0.0", "--target=x86_64-apple-darwin13.0.0", "--host=x86_64-apple-darwin13.0.0"
then perform a brew install pjsip, and it looks like you have 64bit pjsip.
Probably fixable with an edit of the recipe to get the proper arch, rather than just passing in the --build, --host and --target options.
I'm trying to install Bugzilla but encounter a Perl problem.
When installing required Perl modules, I get the following error message:
ERROR: Using install-module.pl requires that you install a compiler, such as gcc.
gcc 4.2.3 is installed and in the path. I'm using perl v 5.8.6 OS: Linux DiskStation 2.6.32.12
Another thread on Stackoverflow refers to PerlGcc but it seems to work on Solaris only.
How can I make Perl find gcc?
I'm guessing you're talking about this thread. Assuming that the guy talking about the version of gcc being relevant was onto something, could you check that you don't have an older version of gcc lying around somewhere higher in the path with
$ which gcc