I would like to use objdump to view binary m32c files. When I type in: objdump -i the architecture list returned is i386 based. Looking at the source code from binutils it appears that the m32c architecture is supported, just not compiled in by default.
I've also seen arm-none-eabi-objdump for the embedded ARM market. What I would like to create is a compiled version of objdump for the m32c architecture. Has anyone done something similar?
Building binutils for a specific target is pretty straightforward. If binutils is to be hosted on Windows, you will need to install MinGW/GCC and the Msys shell environment. Then from within a Linux bash shell or msys on Windows:
Create a directory to build the tools ()
Create a directory to which to install the tools ()
Extract the binutils package into , hereafter refers to the binutils verion you are building, and is indicated in the package name (binutils-.tar.bz2)
Working from , configure the package for the appropriate target and host:
../binutils-<version>/configure --target m32c-elf --prefix <installdir>
In Windows you can also add to the configure command line --enable-win32-registry=gnu_m32c to allow path lookup via the registry. The toolchain name gnu_m32c is arbitrary - you can call it what you like.
Run make to build the tools.
Run make install-strip to install the tools.
Note:
If you are installing on Windows and used the --enable-win32-registry option but subsequently choose to move the installation, or are installing your pre-build tools on a new host, you will need to modify the registry to match; this can be done in regedit editing the key HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\gnu_m32c, adding/modifying the item:"BINUTILS"="<installdir>" if you have installed GCC as well there are related keys:
"GCC"="<gccinstalldir>"
"G++"="<gppinstalldir>"
Related
so I just downloaded wslusing the wsl --install command using PowerShell
now I'm trying to connect it to Clion which works
i cant add images so here is a link to it
but when i'm tying to build the project i get this error
"CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.20 or higher is required. You are running version 3.16.3"
my cmake file:
cmake_minimum_required(VERSION 3.20)
project(ex2 C)
set(CMAKE_C_STANDARD 99)
add_executable(ex2
ex2.c ex2.h
main1.c
main2.c)
i tried updating wsl using wsl --update (in powershell)
The CMake installation inside the WSL is used. Unfortunately currently snap doesn't seem to be available in WSL, but installing the latest CMake version isn't too complicated nonetheless:
(optional) uninstall the old cmake installation in WSL; personally I don't see any benefit in multiple CMake installations, but there may be valid reasons for this. Most likely this will just makes the use of cmake more complex, since you need to remember which cmake version is used.
Download the appropriate cmake version from the cmake website ( https://cmake.org/download/ ). The version to choose is the tar.gz file under binary distributions for the x86_64 target. To get version 3.21.4 (currently the latest release), you can download the file from https://github.com/Kitware/CMake/releases/download/v3.21.4/cmake-3.21.4-linux-x86_64.tar.gz (Identical to the link on the CMake download page).
Unpack the archive from WSL. Navigate to the directory where you want the cmake installation to recide. This will add the cmake-3.21.4-linux-x86_64 directory containing all the files required to work with cmake to the current working directory. Let's assume you want to add the cmake files to the /opt directory. Furthermore let's assume the windows user name to be fabian, C: to be the primary hard drive and the download to be saved to the Downloads directory in the user directory:
cd /opt
tar -xf /mnt/c/Users/fabian/Downloads/cmake-3.21.4-linux-x86_64.tar.gz
(optional) make CMake available without specifying the path; this could be done as described here: https://unix.stackexchange.com/questions/3809/how-can-i-make-a-program-executable-from-everywhere ; don't do this, if an existing cmake installation is already available in the command line assuming you did install cmake to /opt, the cmake binary recides at /opt/cmake-3.21.4-linux-x86_64/bin
You should now be able to use cmake specifying either the full path to the executable (/opt/cmake-3.21.4-linux-x86_64/bin/cmake assuming you used the /opt directory) or directly via a command after opening the WLS commandline again (provided you followed step 4).
Now the only thing left to do should be telling CLion about the location of the cmake executable. Note that I haven't tested this, since I don't use this IDE. It's working fine using Visual Studio Code though...
I am considering to create a Debian package from an existing library (paho-mqtt-c). The project uses CMake as its build system. After some research I think I need to create two or three different packages:
libpaho-mqtt3 (with library .so files and related stuff)
libpaho-mqtt3-dev (with header files)
also maybe I need a third package with sample files or documentation (called paho-mqtt3?)
I have done some research and it seems there exist at least three different ways how I can create a Debian package when I use CMake as my build system:
Use debmake procedure described in Debian documentation (Chapter 8).
Use cmake-debhelper.
Use dh-cmake
I have looked into all three methods and it seems each has some advantages and disadvantages.
Debmake
As far as I have understood using debmake assumes I have an upstream tarball with the sources and the build system and then I invoke debmake on the extracted tarball. Afterwards I get a lot of templates which I need to manually adjust to fill in the missing gaps. I started doing this but it seems quite complex.
cmake-debhelper
I tried to use it but received lots of errors. The github page has an open issue with no solution so I stopped looking at this. This is also what the paho-mqtt-c build system is currently using, but it does not work due to the issue linked.
dh-cmake
I briefly looked into this and it seems to be the most modern solution and it should be possible to combine this with CPack. However, it seems dh-cmake is only available for Ubuntu 18.04 and 16.04, but I am using Ubuntu 19.10 so I was not able to install dh-cmake on my system.
Have I missed anything in my research? What are the recommended steps to create a Debian package from a software managed with CMake and which documentation is useful to read?
In short, on Ubuntu you need to create at least these files:
debian/
changelog
control
copyright
rules
And then run debuild and it will run cmake install to temporary folder and pack an installable deb package from it.
To quickly create those debian files run dh_make --createorig and press s for source package.
Then you'll need to carefully edit debian files as described in Chapter 4. Required files under the debian directory
of Debian New Maintainers' Guide.
If you need to set cmake properties or make any other configuration then you'll need to adjust override_dh_auto_configure in rules:
#!/usr/bin/make -f
# See debhelper(7) (uncomment to enable)
export DH_VERBOSE = 1
%:
dh $#
override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
-DIWINFO_SUPPORT=OFF
Here the -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) and -DIWINFO_SUPPORT=OFF will be directly passed to cmake.
You can then upload your package to Ubuntu PPA:
debuild -S -I
dput dput ppa:your-launchpad-user/your-ppa ../*_source.changes
After that PPA build bot will compile and publish your package to PPA and you'll see them on https://launchpad.net/~your-launchpad-user/+archive/ubuntu/your-ppa/+packages
Unfortunately there is a lot of other steps, I just described briefly.
The dh-cmake is needed for more sophisticated things. CPack won't work for you if you want to publish to PPA because its buildbot will anyway run debhelper (short version of debuild) so it needs for the debian folder
or you could use cpack with cmake to generate a deb fairly easy to do but cmake and cpack are poorly documented still they work well
I suggest adding the following to the bottom of CMakeLists.txt
# generate postinst file in ${CMAKE_BINARY_DIR} from template #
CONFIGURE_FILE("${CMAKE_SOURCE_DIR}/contrib/postinst.in" "postinst" #ONLY IMMEDIATE)
# generate a DEB when cpack is run
SET(CPACK_GENERATOR "DEB")
SET(CPACK_PACKAGE_NAME ${CMAKE_PROJECT_NAME})
SET(CPACK_SET_DESTDIR TRUE)
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "grizzlysmit#smit.id.au")
SET(CPACK_PACKAGE_VERSION_MAJOR "0")
SET(CPACK_PACKAGE_VERSION_MINOR "0")
SET(CPACK_PACKAGE_VERSION_PATCH "1")
include(GNUInstallDirs)
SET(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_SOURCE_DIR}/docs/CPack.Description.txt")
SET(CPACK_RESOURCE_FILE_README "${CMAKE_SOURCE_DIR}/docs/README.md")
SET(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/docs/LICENCE")
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libreadline8, libreadline-dev")
SET(CPACK_PACKAGE_VENDOR "Grizzly")
# make postinst run after install #
SET(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CMAKE_BINARY_DIR}/postinst;")
include(CPack)
the postisnt is to run a script after the install see CMAKE/CPACK:I want to the deb executes a bash script after installed, but it doesn't work for more on that.
I am cross-compiling a C library using CMake and a toolchain file. My toolchain file sets CMAKE_SYSROOT to the appropriate value so compilation works with no issues. However, when installing, the library does not install to the directory pointed to by CMAKE_SYSROOT. I can achieve that effect by running make install DESTDIR=xxx though.
I understand that there are two separate concepts here:
The cross-compilation toolchain, which consists of binaries that can be run on my local architecture
The CMAKE_SYSROOT which is the root directory of a target-architecture filesystems, containing header files and libraries, passed to e.g. gcc through the --sysroot flag.
I have two questions:
Is it a good idea to conflate the sysroot where my cross-compilation toolchain lives, with the sysroot where all my cross-compiled libraries will be installed? It feels to me like it should be the same, but am not sure, and to CMake it appears they are distinct concepts. Update: answered in the comments below, these are indeed distinct concepts.
What is the modern CMake way to specify the installation directory when cross-compiling like described above? Update: I believe this should be the same as CMAKE_SYSROOT, and I feel CMake should offer a way to only define this once somewhere.
Thanks!
There is no interference between sysroot and install directory (prefix).
Sysroot is given by CMAKE_SYSROOT variable and denotes prefix for tools used during build process.
Install directory(prefix) is given by CMAKE_INSTALL_PREFIX variable and denotes the path, where the project will be used upon installation. E.g. with install prefix /usr/local the project's executable foo expects to be run as /usr/local/bin/foo.
Note, that with default installation procedure, CMake installs files to the host machine. For install files onto the target machine, this procedure is needed to be adjusted. Parameter DESTDIR=xxx for make install is a way for install files directly to the target machine. Another way is to create a package (e.g. with CPack) on host, and install that package on target machine.
Note, that in the above paragraph it is irrelevant, whether cross-compilation took a place or not: it is possible to build the project on one machine and install it to the other, but similar one, without any cross-compilation.
I'm trying to build a cmake project, and the repo I have been given has the lines
find_library(gmp gmp)
if(NOT gmp)
message(FATAL_ERROR "gmp not found")
endif()
which cause CMake configuration to fail.
I have been told this CMake works on Redhat Enterprise Linux 7.3.
I have also been told this repo should build in any Linux environment with the correct libraries installed, and an Ubuntu environment has been specifically referenced.
I am building in Debian 9.4.0, I have installed gmp, libgmp.so is located at /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libgmp.so
and I also have a libgmp.so.10 at /usr/lib/x86_64-linux-gnu/libgmp.so.10.
So, to recap, I have been handed a repo I have been told builds, but it does not build, it fails at this specific step, and I can't get google to give me any relevant results on how to fix the issue/what I am doing wrong.
libgmp is installed, but the development libraries are not.
Cmake find_libraries looks for the files required for software development, and while the libgmp package is installed, the libgmp-dev package is not.
Install libgmp-dev.
CMake doesn't search "so-version" files:
If find_library is called for "gmp" library name, CMake searches libgmp.so file, but not libgmp.so.10 one.
Normally, the library file without so-version is just a soft link to the newest so-version file. If your Linux distro doesn't create such link, you may create it manually:
ln -s libgmp.so libgmp.so.10
If you want CMake to find /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libgmp.so file, which is not under directory normally searched by CMake, you need to hint CMake about it. E.g. with PATHS option:
find_library(gmp gmp PATHS "/usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines")
I've tried official howto but failed. I got error:
"The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library libstdc++-6.dll"
The problem was due the old gcc compiler, bundled with DevKit from rubyinstaller.org (4.5 vs 4.8 on my PC). Use MSYS instead. Assume we have zeromq source inside D:\libs\zeromq, then the procedure is:
Download GUI MinGW installer.
Install base and MSYS (if you already have working gcc compiler you probably only need MSYS).
Launch MSYS environment by executing C:\MinGW\msys\1.0\msys.bat.
Follow Using MSYS with MinGW section:
mount c:/mingw /mingw
cd /d/libs/zeromq
./configure --prefix=/mingw
make
Copy /d/libs/zeromq/src/.libs/libzmq.dll to your desired place.
In fact I needed to use ZeroMQ with C++, so I downloaded zmq.hpp, moved it to include directory, and compiled hwserver.cpp to test it:
C:\MinGW\bin\g++.exe -o hwserver hwserver.cpp -L. -lzmq -ID:\libs\zeromq\include
It worked, but when I launch it I got:
Assertion failed!
Program: D:\tmp\zmq\hwserver.exe
File: D:\libs\zeromq\include/zmq.hpp, Line 280
Expression: rc == 0
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I've managed to get rid of this failure by commenting lines 279, 280. Similar issue