I am trying to build an embedded image where some kernel scripts are in python 2.
The project is abl/tianocore/edk2
It is part of kernel 5.15, it contains some scripts inside Tests folder
In the layer.conf for that layer
The tools are listed like this
# Tools needed on the build host for usage within build tasks by recipes of this layer.
HOSTTOOLS_NONFATAL += "xgettext msgmerge msgfmt gmsgfmt java zip python python2 flex bison"
The make file for Tests folder contains this line
#python RunTests.py
When I execute the make file from command line no errors are thrown
But when I try to build the image using bitbake.
I get syntax errors because the scripts are in python 2 and it is using python3 to compile them
In the make file if I replace
#python RunTests.py
with
#/usr/bin/python RunTests.py
There is no error thrown as it uses the correct python but I can't do this for all make files.
How do I make yocto/poky pick the correct python
Related
Some years ago on Ubuntu 16.0.4 I've used this library: git clone https://github.com/Beckhoff/ADS and using only the make command I got build, compile and finally on the main directory I found a file called AdsLib-Linux.a and maybe nothing more than this.
Now I'm on Ubuntu 20.04 I need this library once again but this times make dosn't produce the same output and looking forth to the ReadMe instructions I finally used that instead of make:
meson build
ninja -C build
That now create a new directory build but no .a file as before on the root directory. Instead a new file in the build directory libADSLib.a is there. The same thing happens using right the make command.
Maybe the author changed over the years something on the config files or the behavior of the tools have changed, but I cannot get the former file anymore and I need it for other referencing code that now is not executing anymore.
Looking to the MakeFile I found that in the example folder, differently from the one on the parent directory, the MakeFile has something like that:
$(warning ATTENTION make is deprecated and superseeded by meson)
...
${PROGRAM}: LIB_NAME = ../AdsLib-${OS_NAME}.a
...
But all i've tried reading the guides on meson and ninja about setup, configure, build, and so on, did not produce anymore that file.
I've tried also to first build and then copy all files form the example folder to the parent directory and then build again, but again no .a file there.
How's the right way to configure the build process corectly so that this -Linux.a file is created. Or if not possibile anymore, what does it now produce I can use instead of what produced before?
Meson is a build system generator, similar to CMake or somewhat like ./configure, you need to run meson, then run ninja to actually build something.
You need to run both meson and ninja:
meson setup builddir
ninja -C builddir
Once you do that successfully, there will be a libAdsLib.a inside the builddir directory.
Let me correct a bit #dcbaker, according to their README you should setup build as build directory:
# configure meson to build the library into "build" dir
meson build
# let ninja build the library
ninja -C build
Of course, in general, it shouldn't be specific, but their example code is written in a weird way so this path is hard-coded. So, to use the example:
# configure meson to build example into "build" dir
meson example/build example
# let ninja build the example
ninja -C example/build
# and run the example
./example/build/example
About the library: it's now libAdsLib.a and produced in build directory. The name is set here and it's now in linux naming style, the old one - not. So, you have options:
Update your configuration/build files (Makefile?) where you use it
Copy or make symbolic link, e.g.
$ ln -s <>/build/libAdsLib.a <target_path>/AdsLib-Linux.a
Above it's very dependent on your development environment, do you have installation or setup scripts for it? do you permissions to modify/configure parameters for target application? do you need to support both old and new names? - many questions not related to original question about meson.
I have cmake target which runs a setup.exe on windows which installs a tool using add_custom_target as follows
# TOOL_TEMP_INSTALL_PATH is the installation path which is set earlier in cmake
add_custom_target(
install_tool
COMMAND ${TOOL_TEMP_DIR}/setup.exe /DIR=${TOOL_TEMP_INSTALL_PATH}
)
After the installation, I want to replace text in a configuration file located at ${TOOL_TEMP_INSTALL_PATH}/tool.ini replacing a line of text "LICENSE_FILE=Enter License server" with "LICENSE_FILE=30309#server"
Following commands will achieve this but this needs to be run after install_tool target is built.
file(READ "${TOOL_TEMP_INSTALL_PATH}/tool.ini" filedata)
string(REGEX REPLACE "LICENSE_FILE=Enter License server here"
"LICENSE_FILE=30309#server" filedata "${filedata}")
file(WRITE "${TOOL_TEMP_INSTALL_PATH}/tool.ini" "${filedata}")
How can I add these commands as a dependency to install_tool? Or is there a better way to achieve this on windows?
Since you want to run two things in order as part of the same target, you can use multiple COMMAND entries in the same target. The difficulty is that COMMAND can't handle CMake code, but only system commands. The typical solution is to call CMake in a subshell on a script file:
COMMAND ${CMAKE_COMMAND} -P path_to_script
So, place your file modification commands in a file in your source tree called license-install.cmake, and add another COMMAND to your add_custom_target
Hint: You might consider add_custom_command instead, so you can specify a file in the installed tree as a dependency. This will allow CMake to see the installed tool as a build product, and to skip the install step if the tool is already installed. You'll still need an add_custom_target with a dependency on your command output to hook it in correctly.
This is the service file for php, it works well
[Unit]
[Service]
ExecStart=/usr/bin/env php /path/to/server.php
[Install]
this one is for python
[Unit]
[Service]
ExecStart=/usr/bin/python3 /path/to/server.py
[Install]
When I try this for Golang it's not working, what's wrong?
[Unit]
[Service]
ExecStart=/usr/bin/go /path/to/server.go
Environment=GOPATH="/home/test/go"
[Install]
It worked after trying every single output from whereis go
this is the conf file for Golang:
ExecStart=/usr/local/go/bin/go run /home/testbed/Desktop/test/test.go
Python and PHP are interpreted languages which means they need to be run through program called interpreter (for PHP that's /usr/bin/php and for Python /usr/bin/python) which takes source code (your .php or .py file) and interprets it (translates source into machine code understood by computer as it runs). So anyone who wants to run your program needs:
your program (source code .py files)
any libraries you used
interpreter
Golang isn't like that, it is compiled language (like C or C++) instead. In case of compiled languages you have a program called compiler which takes source code (your .go file) and produces (compiles) binary file directly understood by any computer of same class (having same or compatible CPU, OS, etc.) without need of any interpreter or compiler. In Golang for most cases also all libraries you use are also compiled in into that binary making it super convenient and easy for users.
In Golang, rather than using go run command which is shortcut for compile and execute once. You want to finish your coding, then compile program using go build command into an executable form (on Windows that's .exe file and on Linux that will be binary - executable file without extension) and then execute that from your service file.
Let's suppose your code file is server.go:
go build -o server server.go will compile your source and produce executable called server (we forced go build command to name it server by adding -o server)
You can run ./server as many times as you want.
If you need to update code then you also need to re-run go build -o server server.go and that will generate updated binary. Which is slightly different than in PHP or Python (so be wary of this).
Then you just update your service file (see go not needed at all):
[Service]
ExecStart=/path/to/server
[Install]
Compiling code from service file is not good idea as it requires go installed on machine that runs program. Also in Golang programs often pull libraries from Github and if someone changes library so your program doesn't compile anymore service won't run.
The title should have two subtitles:
What is the pathname to any installed libraries in the Travis CI environment?
or
How do I get my Makevars file portable for NetCDF libraries??
Background:
I am developing and R package that is supposed to work with a shared library I have written in Fortran. I want to check my builds with TravisCI, so my package is currently on GitHub.
So upon package installation, the Fortran source code should be compiled. I can do this locally, but TravisCI errors with the following message:
gfortran -fdefault-real-8 -c HANDLE_ERR.f90
HANDLE_ERR.f90:4: Error: Can't open included file 'netcdf.inc'
make: *** [HANDLE_ERR.o] Error 1
Which I understand as the compiler not finding the NetCDF library, which I made sure I installed by adding this to my .travis.yml:
before_install:
- sudo apt-get install libnetcdf-dev -y
Example
I have created a minimal working example, which is failing in TravisCI, with the error message (above) I am getting on my big project.
See here for the travis build https://travis-ci.org/teatree1212/nctest
you can access my minimal working example repository from there, but here is the link as well: https://github.com/teatree1212/nctest/tree/master
The compilation works when I do it locally, as I can specify the NetCDF library directories. I don't know where these are installed in the Travis build environment, so I think this is where my problem lies at the moment.
However, I would like to make this package portable and not only make it work in the travis container. Therefore these two questions:
What is the pathname to any installed libraries in the Travis CI environment?
and more importantly:
How do I make my Makevars file portable for compiling with NetCDF libraries?
I am working on a kernel module for a project using Yocto Linux (version 1.3). I want to use the kernel headers and the compiler and libraries from my Yocto project, but develop the kernel module without needing to run bitbake every time. My initial solution to this was to execute the devshell task and extract the environment variables using something like this:
bitbake mykernel -c devshell
Then in the new xterm window bitbake opened for me:
env | sed 's/\=\(.*\)/\="\1"/' > buildenv #put quotes around r-values in env listing
^D #(I leave the devshell)
Then copy this to my development directory and source it before running make with all of its options
KERNEL_PATH=/mypathto/build/tmp/sysroots/socfpga_cyclone5/usr/src/kernel
source ./buildenv && make -C $KERNEL_PATH V=1 M=`pwd` \
ARCH=arm CROSS-COMPILE=arm-linux-gnueabihf- \
KERNEL_VERSION=3.13.0-00298-g3c7cbb9 \
CC="arm-linux-gnueabihf-gcc -mno-thumb-interwork -marm" \
LD=arm-linux-gnueabihf-ld AR=arm-linux-gnueabihf-ar
Now to my questions:
Am I going about this completely wrong? What is the recommended way to cross-develop kernel modules? I am doing it this way because I don't want to open a bitbake devshell and do my code development in there every time.
This sort of works (I can compile working modules) but the make script gives me an error message saying that the kernel configuration is invalid. I have also tried this with KERNEL_PATH set to the the kernel package git directory (build/tmp/work///git (which contains what appears to be a valid .config file) and I get a similar error.
How can I extract the env without needing to open a devshell? I would like to write a script that extracts it so my coworkers don't have to do it manually. The devshell command opens a completely separate Xterm window, which rather dampens its scriptability...
the sdk installer is what you are looking for:
bitbake your-image -c populate_sdk
then, from your build directory go to tmp/deploy/sdk
and execute the generated shell script.
this script will allow you to generate and install an sdk.
Not only the sdk will allow you to (cross) compile your kernel by providing the needed environment variables and tools, but it will also provide a sysroot + a standalone toolchain to help you easily (and by easily I mean really easily) crosscompile applications with the autotools (as long as you provide Makefile.am and configure.ac)
just source the environment-setup-* file, got to your kernel directory and compile.
Or, for application developpment based on the autotools,
go to the folder containing your project (sources + Makefile.am and configure.ac)
and do:
libtoolize --automake
aclocal
autoconf
automake -a
now your project is ready for compilation:
./configure $CONFIGURE_FLAGS
make
make install DESTDIR=path/to/destination/dir
If you're after a quick hack, instead of Ayman's more complete solution, the scripts run to complete each build stage are available in the directory:
./build/tmp/work/{target_platform}/{package}/{version}/temp/run.do_{build_stage}
These scripts can be run standalone from the ./temp/ directory, and contain all of the environment variables required.