Buildroot fails, when building perf with the following error:
>>> perf custom Building
Your kernel version is too old and does not have the perf tool.
At least kernel 2.6.31 must be used.
package/pkg-generic.mk:184: recipe for target recipe for target '[..]/buildroot/output/build/perf-custom/.stamp_built' failed
make: *** [ [..]/buildroot/output/build/perf-custom/.stamp_built] Error 1
The kernel source is in a seperate directory and has got version 4.0.0. So. the error is not true.
│ │ [*] Linux Kernel │ │
│ │ Kernel version (Custom override kernel source) ---> │ │
│ │ (linux/linux-kernel) PATH of custom override kernel │ │
The target is an armv7
How could I fix the buildroot config, or set the correct version?
(If this is not possible, how to build perf manually?)
Related
tl;dr how do I list the minimum rust version required for my project and dependencies?
In my rust project, each entry in Cargo.toml section [dependencies] may have some minimum rust version required. I want to list those version requirements per dependency. This is in order to understand the minimum rust version for the my rust project.
Of course, for each dependency, I could find it's Cargo.toml and note any rust-version entry. And then repeat that for each of it's dependencies. But that is a time-consuming manual process. I was hoping for a cargo command or a tool that would effectively do this.
You can install and use cargo-msrv for that ("MSRV" means "minimum-supported Rust version"); it has multiple commands that can help.
For example cargo msrv list will list the advertised Rust versions of your crate, its dependencies, and any transitive dependencies. Below is for an empty package with a chrono dependency:
> cargo msrv list
Fetching index
┌────────┬───────────────────────────────────────────────────────────────────────────┐
│ MSRV ┆ Dependency │
╞════════╪═══════════════════════════════════════════════════════════════════════════╡
│ ┆ mycrate, chrono, winapi, wasm-bindgen, time, num-traits, num-integer, │
│ ┆ js-sys, iana-time-zone, winapi-x86_64-pc-windows-gnu, │
│ ┆ winapi-i686-pc-windows-gnu, wasm-bindgen-macro, cfg-if, wasi, libc, │
│ ┆ autocfg, iana-time-zone-haiku, core-foundation-sys, │
│ ┆ android_system_properties, wasm-bindgen-macro-support, │
│ ┆ wasm-bindgen-shared, wasm-bindgen-backend, codespan-reporting, cc, log, │
│ ┆ bumpalo, unicode-width, termcolor, winapi-util │
├╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ 1.0.0 ┆ scratch │
├╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ 1.31.0 ┆ quote, syn, proc-macro2, unicode-ident │
├╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ 1.34.0 ┆ link-cplusplus │
├╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ 1.48.0 ┆ cxx-build, cxx, cxxbridge-macro, cxxbridge-flags │
├╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┤
│ 1.56.0 ┆ once_cell │
└────────┴───────────────────────────────────────────────────────────────────────────┘
You may notice though, that many crates do not have a rust-version documented in their Cargo.toml. So you should be careful that, just because highest minimum reported is 1.56.0, you don't mistake that for a guarantee that 1.57.0 (for example) will work.
For that, the basic cargo msrv will install and check your crate with various versions of Rust to see whether it works or not:
> cargo msrv
Fetching index
Determining the Minimum Supported Rust Version (MSRV) for toolchain x86_64-unknown-linux-gnu
Using check command cargo check
Check for toolchain '1.60.0-x86_64-unknown-linux-gnu' succeeded
Check for toolchain '1.58.1-x86_64-unknown-linux-gnu' succeeded
Check for toolchain '1.57.0-x86_64-unknown-linux-gnu' succeeded
Check for toolchain '1.56.1-x86_64-unknown-linux-gnu' succeeded
Finished The MSRV is: 1.56.1
Trying to add the Debian package libsystemd. But I keep get the following error after, not sure how to solve this.
ERROR: Nothing PROVIDES 'libsystemd' (but example.bb DEPENDS on or otherwise requires it). Close matches:
libteam
systemd
systemd RPROVIDES libsystemd
NOTE: Runtime target 'example' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['example', 'libsystemd']
Missing or unbuildable dependency chain was: [ 'example', 'libsystemd']
fatal error: systemd/sd-daemon.h: No such file or directory | 16 | #include <systemd/sd-daemon.h>
Related post: Yocto Build Dependency on Debian Package
example.bb
DESCRIPTION = "Example Utilities"
LICENSE = "CLOSED"
inherit cmake systemd useradd
require common.inc
S = "${WORKDIR}/git/example-server"
DEPENDS = "simple-web-server boost sqlite3 libsystemd"
systemd/sd-daemon.h is provided by systemd recipe:
In image (${D}) folder there is:
$ tree usr/include/
usr/include/
├── libudev.h
└── systemd
├── sd-bus.h
├── sd-bus-protocol.h
├── sd-bus-vtable.h
├── _sd-common.h
├── sd-daemon.h <======(Header file you are looking for)
├── sd-device.h
├── sd-event.h
├── sd-hwdb.h
├── sd-id128.h
├── sd-journal.h
├── sd-login.h
└── sd-messages.h
Also, libsystemd is provided by systemd package, so change DEPENDS to:
DEPENDS = "simple-web-server boost sqlite3 systemd"
# ^
# |
# ===========================================
Trying to use a specific version of a node module (v0.2.0) in my own project, but one of my dependencies requires v0.1.8 of the same module. No issue, I thought, that dependency will use v0.1.8 in its nested node_modules folder and my app will use v0.2.0 in my project's node_modules folder. I added v0.2.0 as a dependency to my package.json and ran npm install again. However, for some reason my app points to the other dependency's v0.1.8 module (in its nested node_modules) when I ctrl-click it, instead of the expected v0.2.0 module correctly installed in the project's own node_modules folder. Here's the code I'm using to import from the modules (#metaplex/js relies on v0.1.8 of #solana/spl-token, while I need to use v0.2.0 of #solana/spl-token in my own app):
import { ... } from "#solana/spl-token";
import { ... } from '#metaplex/js';
I verified that the v0.1.8 spl-token was installed in ./node_modules/#metaplex/js/node_modules/#solana/spl-token, and the v0.2.0 spl-token was installed in ./node_modules/#solana/spl-token. I also ran npm ls #solana/spl-token to make sure it was in the dependency tree, and here are the results:
├─┬ #metaplex-foundation/mpl-token-metadata#1.2.5
│ └── #solana/spl-token#0.1.8
├─┬ #metaplex/js#4.12.0
│ ├─┬ #metaplex-foundation/mpl-auction#0.0.2
│ │ └── #solana/spl-token#0.1.8
│ ├─┬ #metaplex-foundation/mpl-metaplex#0.0.5
│ │ ├─┬ #metaplex-foundation/mpl-token-metadata#0.0.2
│ │ │ └── #solana/spl-token#0.1.8 deduped
│ │ └── #solana/spl-token#0.1.8
│ ├─┬ #metaplex-foundation/mpl-token-vault#0.0.2
│ │ └── #solana/spl-token#0.1.8
│ └── #solana/spl-token#0.1.8
└── #solana/spl-token#0.2.0
I can't figure out why my code still imports from the wrong version used by another dependency when I installed the correct version in my project's node_modules folder. Is there a workaround or solution to solve this?
fairly new to node, sorry
Edit: (my project is a typescript react project) did some more poking around and apparently, v0.1.8 of the module's package.json's types property points to an *.d.ts file like this:
declare module '#solana/spl-token' {
export //functions, fields, etc
}
while v0.2.0's package.json's types property points to a simple *.d.ts file like
export * from './instructions/index';
...
(note there is no specific declare keyword for the module itself)
and each function has a separate *.d.ts where the specific member is declared, as such in functionName.d.ts:
export declare function functionName(...): Promise<...>;
I don't know if this change causes some type of namespace conflict but it seems like this is a very specific error having to do with this particular module and not something generally wrong with node.
What do you mean by very specific error ?
This Is very common issue
At yow tsconfig.json set the baseUrl AND paths
{
...
"baseUrl":"./node_modules",
"paths":{
"name-of-the-package":[
"relative-to-baseurl/position/where/yow-code-is"
]
}}
The position of yow code Is relative to baseUrl.
I currently have a c++ project which depend on some external shared objects (.so). My current directory looks like this:
├── src
│ └── .cpp files
├── include
│ ├── glad
│ │ └── .h files
│ └── fmod
│ ├── core
│ │ └── .h files
│ └── studio
│ └── .h files
├── lib
│ └── fmod
│ ├── core
│ │ └── .so files
│ └── studio
│ └── .so files
├── Makefile.am
├── configure.ac
I want to compile this project while simultaneously copying those .so files towards /usr/lib or /usr/local/lib, however I can't seem to be able to do this!
The following is my configure.ac file
AC_INIT([autoGL], 1.0)
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_PROG_CXX
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
And my Makefile.am
bin_PROGRAMS = autogl
autogl_SOURCES = src/Source.cpp
autogl_SOURCES+= src/glad.c
autogl_LDADD = -lglfw -ldl
autogl_LDADD+= -L lib/fmod/core -lfmod
autogl_LDADD+= -L lib/fmod/studio -lfmodstudio
autogl_LDFLAGS = -Wl,--no-as-needed,-rpath,lib/fmod/core,-rpath,lib/fmod/studio
autogl_CPPFLAGS = -I include
autogl_CPPFLAGS+= -I include/fmod/core
autogl_CPPFLAGS+= -I include/fmod/studio
autogl_CPPFLAGS+= -I include/fmod/fsbank
You can see that I'm linking every library using the link flags -L lib/fmod/---- -library. Initially, the seventh line of my Makefile.am was only
autogl_LDFLAGS = -Wl,--no-as-needed
resulting in the following g++ code, which was successfull and gave me an executable file
g++ -g -O2 -Wl,--no-as-needed -o autogl autogl-Source.o autogl-glad.o -lglfw -ldl -L lib/fmod/core -lfmod -L lib/fmod/studio/ -lfmodstudio
However, when tried to run this, I would get the following error:
./autogl: error while loading shared libraries: libfmod.so.12: cannot open shared object file: No such file or directory
My shared objects are not being copied to /usr/lib or /usr/local/lib.
With the addition of
autogl_LDFLAGS = -Wl,--no-as-needed,-rpath,lib/fmod/core,-rpath,lib/fmod/studio
since we are linking rpath to our lib files, the program has no problem running. However, if I run make install, the rpath being linked would be /usr/bin/lib/fmod/core and /usr/bin/lib/fmod/studio, which clearly don't have the needed files. My .so files are still not being copied anywhere. I want to copy my .so files directly to /usr/local/lib so that my program can run without me having to link it directly.
How can I force automake to copy these .so files directly to a folder of my choice? (preferable /usr/local/lib).
Found a solution!
Autotools also offers the possibility to transfer data. I added the following to my Makefile.am
flashdir=$(prefix)/lib
flash_DATA= lib/fmod/core/libfmodL.so \
lib/fmod/core/libfmodL.so.12 \
lib/fmod/core/libfmodL.so.12.10
.....
This adds all of my .so files to $(prefix)/lib, which usually is /usr/local/lib.
However, there is a problem, particularly in Ubuntu, where /usr/local/lib is not by default on /etc/ld.so.conf.d, so libraries on /usr/local/lib are not used.
To solve this I added the following line to my makefile.am
install-data-hook:
ldconfig $(prefix)/lib
This creates a hook which runs AFTER the lib files are already added to $(prefix)/lib, which, when run, adds the folder to /etc/ld.so.conf.d, so now after make install, everything runs smoothly.
I have crate A that depend on B and B depend on rust-nmea crate.
If I build crate A I got bunch of errors (all of them that missed use std::error::Error;) during build of rust-nmea dependency:
error[E0599]: no method named `description` found for type `nom::Err<&[u8]>` in the current scope
--> /home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/src/parse.rs:100:44
|
100 | IError::Error(e) => e.description().to_string(),
| ^^^^^^^^^^^
|
= help: items from traits can only be used if the trait is in scope
= note: the following trait is implemented but not in scope, perhaps add a `use` for it:
candidate #1: `use std::error::Error;`
But if I go to source tree of B crate and run cargo build,
all build without any error (if you follow me A depend on B and B depend on rust-nmea),
also if go to /home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/ (see compile error) and run cargo build then all good.
cargo tree show for A:
│ ├── chrono v0.4.0
│ │ ├── num v0.1.40
│ │ │ ├── num-integer v0.1.35
│ │ │ │ └── num-traits v0.1.40
│ │ │ ├── num-iter v0.1.34
│ │ │ │ ├── num-integer v0.1.35 (*)
│ │ │ │ └── num-traits v0.1.40 (*)
│ │ │ └── num-traits v0.1.40 (*)
│ │ └── time v0.1.38
│ │ └── libc v0.2.27
├── nmea v0.0.6
│ ├── chrono v0.4.0 (*)
│ └── nom v3.2.0
│ └── memchr v1.0.1 (*)
and for cached by cargo rust-nmea:
├── chrono v0.4.0
│ ├── num v0.1.40
│ │ ├── num-integer v0.1.35
│ │ │ └── num-traits v0.1.40
│ │ ├── num-iter v0.1.34
│ │ │ ├── num-integer v0.1.35 (*)
│ │ │ └── num-traits v0.1.40 (*)
│ │ └── num-traits v0.1.40 (*)
│ └── time v0.1.38
│ └── libc v0.2.27
└── nom v3.2.0
└── memchr v1.0.1
└── libc v0.2.27 (*)
so for both good and bad case used the same dependencies.
If run cargo build -v -j1, I got rustc command line for both cases.
The only difference for good and bad case is this part:
-L dependency=/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/target/debug/deps --extern chrono=/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/target/debug/deps/libchrono-8e9e54e691d9b988.rlib --extern nom=/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/target/debug/deps/libnom-b72336f662b090c1.rlib
bad case have different path to libraries and libnom-e2ec53418967eac0.rlib instead of libnom-b72336f662b090c1.rlib, while libchrono-8e9e54e691d9b988.rlib match.
The crates A and B are close sourced and I can not reduce problem to more simple case. nom crates not used in A and B except via rust-nmea.
rust-nmea is used in simple way, just nmea = 0.0.6 in Cargo.toml.
No flags or so on things.
Any idea why crate dependecy with the same flags (no flags at all)
may produce or not produce syntax error?
I found source of problem,
crate A has second level dependicies with cexpr,
cexpr has nom = {version = "^3", features = ["verbose-errors"] } in Cargo.toml,
rust-nmea also depend on nom, so we have compile time error.