On Ubuntu 14.04
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
Building a Yocto Poky image using the fido branch
inherit core-image
IMAGE_FEATURES += "x11-base x11-sato package-management ssh-server-dropbear"
IMAGE_INSTALL += "chromium \
lsb \
kernel-modules \
alsa-utils \
... and I am getting this sort of message
I look like it related to the Chromium recipe /meta-browser/recipes-browser/chromium/chromium_45.0.2454.85.bb which starts as such
include chromium.inc
DESCRIPTION = "Chromium browser"
DEPENDS += "libgnome-keyring"
and I get this message
ERROR: Logfile of failure stored in: /home/joel/yocto/build-fido/tmp/work/cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi/chromium/45.0.2454.85-r0/temp/log.do_configure.28622
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| Updating projects from gyp files...
| Package xkbcommon was not found in the pkg-config search path.
| Perhaps you should add the directory containing `xkbcommon.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'xkbcommon' found
| gyp: Call to 'pkg-config --cflags xkbcommon' returned exit status 1.
| WARNING: exit code 1 from a shell command.
What I have tried
Installed the library
$ sudo apt-get install libxkbcommon-x11-dev
Search for xkbcommon.pc
$ apt-file search xkbcommon.pc
libxkbcommon-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/xkbcommon.pc
pkg-config
joel#linux-Lenovo-G50-70:~/yocto/build-fido$ pkg-config --cflags xkbcommon
<=== Return is EMPTY (?)
joel#linux-Lenovo-G50-70:~/yocto/build-fido$ pkg-config --libs xkbcommon
-lxkbcommon <=== Looks correct
Added PKG_CONFIG_PATH
$ PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig/
$ export PKG_CONFIG_PATH
$ env | grep PKG
PKG_CONFIG_PATH=:/usr/lib/x86_64-linux-gnu/pkgconfig/
but I am still getting the same message when running bitbake
Any suggestions?
Find xkbcommon
$ find /usr/lib/ -name *xkbcommon*
/usr/lib/x86_64-linux-gnu/libxkbcommon.so
/usr/lib/x86_64-linux-gnu/libxkbcommon.so.0.0.0
/usr/lib/x86_64-linux-gnu/libxkbcommon-x11.so.0.0.0
/usr/lib/x86_64-linux-gnu/libxkbcommon-x11.a
/usr/lib/x86_64-linux-gnu/libxkbcommon.a
/usr/lib/x86_64-linux-gnu/libxkbcommon-x11.so.0
/usr/lib/x86_64-linux-gnu/libxkbcommon-x11.so
/usr/lib/x86_64-linux-gnu/pkgconfig/xkbcommon.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/xkbcommon-x11.pc
/usr/lib/x86_64-linux-gnu/libxkbcommon.so.0
In this case, it was the chromium recipe that failed to find libxkbcommon. As the error occurred when building a recipe for the target system, we need to tell the build system that the chromium recipe has a dependency on libxkbcommmon.
This can be done by adding
DEPENDS += "libxkbcommon"
to the chromium recipe.
It's worth noting, that libxkbcommon quite likely is an optional dependency, and in that case, it should be handled by a suitable PACKAGECONFIG. (See PACKAGECONFIG in ref.manual).
Note: I've never built chromium myself, thus I'd prefer to not suggest any suitable PACKAGECONFIG.
I think the Chromium_45 recipe is taken down since the last time I saw it (don't see it anymore).
Anyway, this is what I did to Chromium_40.
I have disabled Wayland (ozone-wayland in Chromium) so that it will only use x11.
In local.conf, I added
CHROMIUM_ENABLE_WAYLAND = "0"
By doing this, I will bypass CHROMIUM_WAYLAND_DEPENDS = "wayland libxkbcommon"
CHROMIUM_X11_DEPENDS = "xextproto gtk+ libxi libxss"
CHROMIUM_X11_GYP_DEFINES = ""
CHROMIUM_WAYLAND_DEPENDS = "wayland libxkbcommon"
CHROMIUM_WAYLAND_GYP_DEFINES = "use_ash=1 use_aura=1 chromeos=0 use_ozone=1"
python() {
if d.getVar('CHROMIUM_ENABLE_WAYLAND', True) == '1':
d.appendVar('DEPENDS', ' %s ' % d.getVar('CHROMIUM_WAYLAND_DEPENDS', True))
d.appendVar('GYP_DEFINES', ' %s ' % d.getVar('CHROMIUM_WAYLAND_GYP_DEFINES', True))
else:
d.appendVar('DEPENDS', ' %s ' % d.getVar('CHROMIUM_X11_DEPENDS', True))
d.appendVar('GYP_DEFINES', ' %s ' % d.getVar('CHROMIUM_X11_GYP_DEFINES', True))
}
P.S.: One more thing I found weird is use-egl.
PACKAGECONFIG[use-egl] = ",,virtual/egl virtual/libgles2" is overrided with PACKAGECONFIG[use-egl] = "" so I have removed PACKAGECONFIG[use-egl] = "" from chromium.inc
PACKAGECONFIG ??= "use-egl"
# this makes sure the dependencies for the EGL mode are present; otherwise, the configure scripts
# automatically and silently fall back to GLX
PACKAGECONFIG[use-egl] = ",,virtual/egl virtual/libgles2"
# Additional PACKAGECONFIG options - listed here to avoid warnings
PACKAGECONFIG[component-build] = ""
PACKAGECONFIG[disable-api-keys-info-bar] = ""
PACKAGECONFIG[ignore-lost-context] = ""
PACKAGECONFIG[impl-side-painting] = ""
PACKAGECONFIG[use-egl] = ""
PACKAGECONFIG[kiosk-mode] = ""
Related
I've built a simple recipe which works as long as I don't need gps.h:
recipes/foo (dunfell) $ cat foo_3.0.0.bb
DESCRIPTION = "FOO Daemon"
LICENSE = "CLOSED"
SRC_URI = " file://*.* \
"
S = "${WORKDIR}"
INSANE_SKIP_${PN} = "ldflags"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"
do_compile() {
cd ${S}/src
make
cp foo ~/
cd -
}
do_install() {
install -d ${D}${bindir}
install -m 0755 foo ${D}${bindir}
}
gps.h is in /usr/include on my local machine, but as Yocto is cross-compiling it provides a reasonable explanation of why it can't use the local /usr/include/gps.h:
cc1: error: include location "/usr/include" is unsafe for cross-compilation [-Werror=poison-system-directories]
foo.c:54:10: fatal error: gps.h: No such file or directory
54 | #include <gps.h>
| ^~~~~~~
cc1: all warnings being treated as errors
I've tried IMAGE_INSTALL_append " libgps-dev" and " gps-lib-dev" in my layer.conf but neither of those work.
How can I get the gps.h header into my Yocto project/recipe at build time?
Let me copy your recipe and add some comments first:
DESCRIPTION = "FOO Daemon"
LICENSE = "CLOSED"
# --- COMMENT ---
# It is not recommended to use "*" with SRC_URI,
# as Yocto will not keep track of your files if you edit them
# so it will never rebuild automaticall after a change
# Best practice is to sepecify the local files like:
# SRC_URI = "file://src"
# This will make bitbake unpacks the "src" folder into ${WORKDIR}
# --- COMMENT ---
SRC_URI = " file://*.* \
"
# --- COMMENT ---
# The ${S} variable is the defautl workind directory for compilation tasks,
# do_configure, do_compile, ...,
# So, if you have "src" folder that will be unpacked into ${WORKDIR}
# you need to set S to that:
# S = "${WORKDIR}/src"
# --- COMMENT ---
S = "${WORKDIR}"
INSANE_SKIP_${PN} = "ldflags"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"
# --- COMMENT ---
# If your project has a "Makefile" you can use the "autotools" class
# it runs oe_runmake automatically
# inherit autotools
# If you want to copy the output to your home directory you can do it in "do_install"
# If you use autotools you do not need do_compile
# --- COMMENT ---
do_compile() {
cd ${S}/src
make
cp foo ~/
cd -
}
do_install() {
install -d ${D}${bindir}
install -m 0755 foo ${D}${bindir}
}
# --- COMMENT ---
# Do not forget to specify your output files into FILES for do_package to work well
# FILES_${PN} = "${bindir}/foo"
# --- COMMENT ---
Now, after dealing with that, if your recipe requires something at build-time, than the dependency needs to exist in the same recipe's workding directory, because if you are adding libgps into IMAGE_INSTALL it will be present in the rootfs but not during your build time.
So, to do that, you need to specify the dependencies recipe with DEPENDS.
I have looked for gps.h and I found it packages with gpsd recipe.
So, try:
DEPENDS += "gpsd"
So, the final recipe would look like the following:
DESCRIPTION = "FOO Daemon"
LICENSE = "CLOSED"
SRC_URI = "file://src"
S = "${WORKDIR}/src"
DEPENDS += "gpsd"
inherit autotools
do_install(){
install -d ${D}${bindir}
install -m 0755 foo ${D}${bindir}
cp foo ~/
}
FILES_${PN} = "${bindir}/foo"
The only thing left is to test.
How can one get a list of all environments that use a certain package in conda?
conda search
Since Conda v 4.5.0, the conda search command has had an --envs flag for searching local environments for installed packages. See conda search -h:
--envs Search all of the current user's environments. If run
as Administrator (on Windows) or UID 0 (on unix),
search all known environments on the system.
A use case given in the original Issue was finding environments with outdated versions of openssl packages:
conda search --envs 'openssl<1.1.1l'
Conda Python API
Here's an example of how to do it with the Conda Python package (run this in base environment):
import conda.gateways.logging
from conda.core.envs_manager import list_all_known_prefixes
from conda.cli.main_list import list_packages
from conda.common.compat import text_type
# package to search for; this can be a regex
PKG_REGEX = "pymc3"
for prefix in list_all_known_prefixes():
exitcode, output = list_packages(prefix, PKG_REGEX)
# only print envs with results
if exitcode == 0 and len(output) > 3:
print('\n'.join(map(text_type, output)))
This works as of Conda v4.10.0, but there since it relies on internal methods, there's no guarantee going forward. Perhaps this should be a feature request, say for a CLI command like conda list --any.
Script Version
Here is a version that uses arguments for package names:
conda-list-any.py
#!/usr/bin/env conda run -n base --no-capture-output python
## Usage: conda-list-any.py [PACKAGE ...]
## Example: conda-list-any.py numpy pandas
import conda.gateways.logging
from conda.core.envs_manager import list_all_known_prefixes
from conda.cli.main_list import list_packages
from conda.common.compat import text_type
import sys
for pkg in sys.argv[1:]:
print("#"*80)
print("# Checking for package '%s'..." % pkg)
n = 0
for prefix in list_all_known_prefixes():
exitcode, output = list_packages(prefix, pkg)
if exitcode == 0 and len(output) > 3:
n += 1
print("\n" + "\n".join(map(text_type, output)))
print("\n# Found %d environment%s with '%s'." % (n, "" if n == 1 else "s", pkg))
print("#"*80 + "\n")
The shebang at the top should ensure that it will run in base, at least on Unix/Linux systems.
I've ran into the same issue and constructed a Powershell script that:
takes a regex query as an argument
goes through all available conda environments (and shows a progress bar while doing so)
lists all packages in each environment
returns the environments that have a package that match the query
per returned environment shows the package name that matched the query
The script is available at the bottom of this answer. I have saved it in a folder that is avaialble in the PATH under the name search-pkg-env.ps1.
The script can be run as follows (here I search for environments with the pip package pymupdf):
PS > search-pkg-env.ps1 pymupdf
Searching 19 conda environments...
py39
- pymupdf 1.18.13
Script
if ($args.Length -eq 0) {
Write-Host "Please specify a search term for that matches the package name (regex)." -BackgroundColor DarkYellow -ForegroundColor White
exit
}
$pkg_regex = $args[0]
$conda_envs = ConvertFrom-JSON -InputObject $([string]$(conda env list --json))
$total = $conda_envs.envs.Count
Write-Host "Searching $total conda environments..."
$counter = 1
ForEach ($conda_env in $conda_envs.envs) {
if ($total -gt 0) {
$progress = $counter / $total * 100
}
else {
$progress = 0
}
# Split the full path into its elements
$parts = $conda_env -Split '\\'
# The last element has the env name
$env_name = $parts[-1]
Write-Progress -Activity "Searching conda environment $env_name for $pkg_regex" -PercentComplete $progress
# Now search the provided package name in this environment
$search_results = ConvertFrom-JSON -InputObject $([string]$(conda list $pkg_regex -n $env_name --json))
If ($search_results.Count -gt 0) {
Write-Host $env_name
foreach ($result in $search_results) {
$pkg_name = $result.name
$pkg_version = $result.version
Write-Host " - $pkg_name $pkg_version"
}
}
$counter++
}
Python + Terminal solution
Jump directly to solution:
Use the following Github script Listing Environments Containing a Set of Packages
You Don't Need to install any Library
Simply copy the script, run and provide the set of packages needed (one or more)
From Scratch Solution:
To find all environments that contains a set of packages (one or more):
Get all the conda environments using Popen and conda env list; this will list all conda envs on your station.
Loop over the packages and check if a package exist in a conda env using Popen and conda list -n <environment>; this will list all available packages in an environment
Check through the output if it exists using either grep, findstr or your platform alternative on the terminal output - or do the search with python.
For each package save in a list
Check through lists for common environments and Voila!
I am attempting to build my haskell project on NixOS.
Running $ stack build gives the following error.
$ stack build
error: attribute ‘ghc822’ missing, at (string):1:53
(use ‘--show-trace’ to show detailed location information)
What does this error mean and how could I proceed? When I run $ stack build --show-trace as suggested, I get the following output, which I do not understand either.
$ stack build --show-trace
Invalid option `--show-trace'
Usage: stack build [TARGET] [--dry-run] [--pedantic] [--fast]
[--ghc-options OPTIONS] [--flag PACKAGE:[-]FLAG]
([--dependencies-only] | [--only-snapshot] |
[--only-dependencies]) ([--file-watch] | [--file-watch-poll])
[--exec CMD [ARGS]] [--only-configure] [--trace] [--profile]
[--no-strip] [--[no-]library-profiling]
[--[no-]executable-profiling] [--[no-]library-stripping]
[--[no-]executable-stripping] [--[no-]haddock]
[--haddock-arguments HADDOCK_ARGS] [--[no-]open]
[--[no-]haddock-deps] [--[no-]haddock-internal]
[--[no-]haddock-hyperlink-source] [--[no-]copy-bins]
[--[no-]copy-compiler-tool] [--[no-]prefetch]
[--[no-]keep-going] [--[no-]force-dirty] [--[no-]test]
[--[no-]rerun-tests] [--ta|--test-arguments TEST_ARGS]
[--coverage] [--no-run-tests] [--[no-]bench]
[--ba|--benchmark-arguments BENCH_ARGS] [--no-run-benchmarks]
[--[no-]reconfigure] [--[no-]cabal-verbose]
[--[no-]split-objs] [--skip ARG] [--help]
Build the package(s) in this directory/configuration
I tried changing my channel to nixos-17.09 instead of nixos-unstable (and running nix-channel --update), but still get the same error.
Output of $ nix-channel --list is shown below.
$ nix-channel --list
stack https://nixos.org/channels/nixos-17.09
nixos https://nixos.org/channels/nixos-17.09
The output of $ nix-env -qaPA 'nixos.haskell.compiler' shows ghc822 to be found.
$ nix-env -qaPA 'nixos.haskell.compiler'
warning: name collision in input Nix expressions, skipping ‘/home/matthew/.nix-defexpr/channels_root/nixos’
nixos.haskell.compiler.ghc6102Binary ghc-6.10.2-binary
nixos.haskell.compiler.ghc704 ghc-7.0.4
nixos.haskell.compiler.ghc704Binary ghc-7.0.4-binary
nixos.haskell.compiler.ghc7102 ghc-7.10.2
nixos.haskell.compiler.integer-simple.ghc7102 ghc-7.10.2
nixos.haskell.compiler.ghc7103 ghc-7.10.3
nixos.haskell.compiler.integer-simple.ghc7103 ghc-7.10.3
nixos.haskell.compiler.integer-simple.ghc742 ghc-7.4.2
nixos.haskell.compiler.ghc742 ghc-7.4.2
nixos.haskell.compiler.ghc742Binary ghc-7.4.2-binary
nixos.haskell.compiler.ghc763 ghc-7.6.3
nixos.haskell.compiler.ghc783 ghc-7.8.3
nixos.haskell.compiler.integer-simple.ghc783 ghc-7.8.3
nixos.haskell.compiler.ghc784 ghc-7.8.4
nixos.haskell.compiler.integer-simple.ghc784 ghc-7.8.4
nixos.haskell.compiler.ghc801 ghc-8.0.1
nixos.haskell.compiler.integer-simple.ghc801 ghc-8.0.1
nixos.haskell.compiler.ghc802 ghc-8.0.2
nixos.haskell.compiler.integer-simple.ghc802 ghc-8.0.2
nixos.haskell.compiler.integer-simple.ghc821 ghc-8.2.1
nixos.haskell.compiler.ghc821 ghc-8.2.1
nixos.haskell.compiler.integer-simple.ghc822 ghc-8.2.2
nixos.haskell.compiler.ghc822 ghc-8.2.2
nixos.haskell.compiler.integer-simple.ghcHEAD ghc-8.3.20170808
nixos.haskell.compiler.ghcHEAD ghc-8.3.20170808
nixos.haskell.compiler.ghcjs ghcjs-0.2.0
nixos.haskell.compiler.ghcjsHEAD ghcjs-0.2.020170323
nixos.haskell.compiler.jhc jhc-0.8.2
nixos.haskell.compiler.uhc uhc-1.1.9.4
I installed ghc8.2.2 via $ nix-env -iA nixos.haskell.compiler.ghc822, and $ ghc --version now returns
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2
However, I still get the error error: attribute ‘ghc822’ missing, at (string):1:54 when attempting to run $ stack build.
Also, I attempted to see what ghc version my stack is using after this install, and this led to the same attribute ‘ghc822’ missing error.
$ stack ghc -- --version
error: attribute ‘ghc822’ missing, at (string):1:54
(use ‘--show-trace’ to show detailed location information)
It seems like your stack wants to retrieve the haskell.packages.ghc822 attribute or perhaps haskell.compiler.ghc822, which is not present in your version of <nixpkgs>.
Please check your channel configuration using sudo nix-channel --list (NixOS) or nix-channel --list. Releases 17.03 and older do not have this attribute. 17.09 and unstable should be fine. To switch your default <nixpkgs> to 17.09, note the name of the channel and run
nix-channel --add https://nixos.org/channels/nixos-17.09 <NAME>
Also run nix-channel --update to make sure you have a recent version. GHC 8.2.2 was added on Oct 31st.
If you don't want to change your channel configuration, I suppose you can set the NIX_PATH environment variable
NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz stack build
Another option is to use a shell.nix. nixos-18.03 comes with ghc 8.2.2, so you can create a shell.nix like:
with import (builtins.fetchGit {
url = https://github.com/NixOS/nixpkgs-channels;
ref = "nixos-18.03";
rev = "cb0e20d6db96fe09a501076c7a2c265359982814";
}) {};
haskell.lib.buildStackProject {
name = "my-project";
buildInputs = [ ghc <otherlibs-here> ];
}
And add the following to your stack.yaml:
nix:
shell-file: shell.nix
Then stack build as usual.
You can provide an old GHC version using a shell.nix file place in the root of your project:
with import (fetchTarball https://github.com/NixOS/nixpkgs/archive/83b35508c6491103cd16a796758e07417a28698b.tar.gz) {};
let ghc = haskell.compiler.ghc802;
in haskell.lib.buildStackProject {
inherit ghc;
name = "myEnv";
buildInputs = [ pcre ];
}
Use a tar url from https://github.com/NixOS/nixpkgs/releases for a version of nixpkgs that contains the GHC version you need.
Then run nix-shell in the root of the project. This will put you into a shell in which you can perform stack build successfully since it would have access to the correct GHC version.
As palik commented, changing the resolver version -- in my case changing
resolver: lts-11.3
to
resolver: lts-9.1
in stack.yaml is a work-around. I do not know what the deeper issue is but would be interested to know.
Update: this post provides a thorough explanation with excellent tips on how to use stackage and nix in concert, including how to reach agreement between package versions of the stack resolver and nix channel.
How to know which resolver to specify in stack.yaml?
Go to this url, which shows stackage snapshots containing ghc:
https://www.stackage.org/package/ghc/snapshots
This will tell you the resolver corresponding to the ghc version you have. For example, I have ghc 8.10.7,
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.7
and doing a find '8.10.7' on that page shows me that corresponds to LTS Haskell 18.28 (ghc-8.10.7). So I would specify resolver: lts-18.28 in my stack.yaml.
(How to find resolvers for a given package was found in an answer here.)
based on #steve-chávez answer
stack.yaml
resolver: lts-13.19
system-ghc: true
install-ghc: false
nix:
enable: true
path: [nixpkgs=./nix/nixpkgs/default.nix]
shell-file: shell.nix
nix/nixpkgs/default.nix
let
spec = builtins.fromJSON (builtins.readFile ./revision.json);
src = import <nix/fetchurl.nix> {
url = "https://github.com/${spec.owner}/${spec.repo}/archive/${spec.rev}.tar.gz";
inherit (spec) sha256;
};
nixcfg = import <nix/config.nix>;
nixpkgs = builtins.derivation {
system = builtins.currentSystem;
name = "${src.name}-unpacked";
builder = builtins.storePath nixcfg.shell;
inherit src;
args = [
(builtins.toFile "builder" ''
$coreutils/mkdir $out
cd $out
$gzip -d < $src | $tar -x --strip-components=1
'')
];
coreutils = builtins.storePath nixcfg.coreutils;
tar = builtins.storePath nixcfg.tar;
gzip = builtins.storePath nixcfg.gzip;
};
in
import nixpkgs
nix/nixpkgs/update.sh
#!/usr/bin/env nix-shell
#!nix-shell -i bash -p nix curl jq
SCRIPT_DIR=$(dirname "$(readlink -f "$BASH_SOURCE")")
owner="nixos"
repo="nixpkgs-channels"
rev="nixos-unstable"
full_rev=$(curl --silent https://api.github.com/repos/$owner/$repo/git/refs/heads/$rev | jq -r .object.sha)
echo "full_rev=$full_rev"
expected_sha=$(nix-prefetch-url https://github.com/$owner/$repo/archive/$full_rev.tar.gz)
cat >"$SCRIPT_DIR/revision.json" <<EOL
{
"owner": "$owner",
"repo": "$repo",
"rev": "$full_rev",
"sha256": "$expected_sha"
}
EOL
shell.nix
{
#
# there are 2 ways of using stack with nix
# - define custom packages in `stack.yaml` `packages` option (https://docs.haskellstack.org/en/stable/nix_integration/#additions-to-your-stackyaml)
# - define custom package in `shell.nix` AND `shell-file: ...` in `stack.yaml` (https://docs.haskellstack.org/en/stable/nix_integration/#additions-to-your-stackyaml)
#
# we are using second option
ghc # stack expect this file to define a function of exactly one argument that should be called ghc
}:
let
# pkgs = import ./nix/nixpkgs/default.nix {}
pkgs = import <nixpkgs> {};
in
with pkgs;
haskell.lib.buildStackProject {
inherit ghc;
name = "myEnv";
buildInputs = [ cabal-install ];
}
This is in my Makefile.core.def:
...
...
module = {
name = mymod;
common = net/mymod.c;
};
...
...
When I tried to build I get:
mv syminfo.lst.new syminfo.lst
cat syminfo.lst | sort | gawk -f /build/boot_project/src/grub/grub2/grub-core/genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1)
grub_efi_get_variable in mymod is not defined
make[5]: *** [moddep.lst] Error 1
mymod.c has "#include <grub/efi/efi.h>" and tries to use "grub_efi_get_variable" function. I see that in syminfo.lst
> more syminfo.lst
...
undefined mymod grub_efi_get_variable
...
Can someone shed a light on the error and how to fix?
Thanks,
P.S I edited Makefile.core.def and Makefile.core.am in /build/boot_project/src/grub/grub2/grub-core/ to include my module and ran autogen.sh in /build/boot_project/src/grub/ to regenerate Makefile.in, then I ran dmake in /build/boot_project/src/grub/
Configuration was ran with --with-platform=efi. Anyhow, I noticed Makefile.core.am has all platform enabled for module mymod. So I edited Makefile.core.def to: module = { name = mymod; common = net/mymod.c; enable = efi}; After re-running autogen.sh, only platform with efi were added to Makefile.core.am and the build works.
I've followed the simple firefox build instructions, but the following error occured:
Gabor#AMANDA /c/dev/mozilla-central
$ ./mach build
0:00.36 C:/mozilla-build/msys/bin/sh.exe -c c:/mozilla-build/python/python.exe
c:/dev/mozilla-central/build/pymake/make.py -f client.mk -s
0:03.79 Adding client.mk options from c:/dev/mozilla-central/.mozconfig:
0:03.79 MOZ_OBJDIR=$(TOPSRCDIR)/obj-ff
0:03.79 FOUND_MOZCONFIG := c:/dev/mozilla-central/.mozconfig
0:04.83 c:\dev\mozilla-central\obj-ff\backend.RecursiveMakeBackend.pp:1:0:Targe
t 'backend.RecursiveMakeBackend' does not match the static pattern 'c:/C'
0:04.83 c:\dev\mozilla-central\client.mk:398:0: command 'c:/mozilla-build/pytho
n/python.exe c:/dev/mozilla-central/build/pymake/pymake/../make.py -j4 -C c:/dev
/mozilla-central/obj-ff' failed, return code 2
0:04.83 c:\dev\mozilla-central\client.mk:185:0: command 'c:/mozilla-build/pytho
n/python.exe c:/dev/mozilla-central/build/pymake/pymake/../make.py -f c:/dev/moz
illa-central/client.mk realbuild' failed, return code 2
0:04.95 0 compiler warnings present.
2
Anyone knows what can be the problem?
Mozconfig only contains this:
mk_add_options MOZ_OBJDIR=#TOPSRCDIR#/obj-ff