Is it possible to have a host package in external tree of buildroot (the tree that is specified by BR2_EXTERNAL variable)? I know that I can implement such package and if there exists any package that depends on it, it will be built. But what if no board package depends on it? That could be the case for example when we need to build a simulator for the supported board. In other words, I need something like Config.in.host in the external directory.
The BR2_EXTERNAL directory needs to contain a top-level Config.in. From there, you can source a host package's Config.in.host just like you do for a target package.
There is no separate Config.in.host for the external, though, so it will never appear in the Host utilities menu, but always in the External options menu.
Related
The situation:
I have a Swift Package, call it lib. lib lives in its own repository. In lib's repository, there are a bunch of local Packages; that is, these are packages that are defined, in lib, using the local-path dependency format, .package(path: "CursorPackage"), and whatnot.
All of this is fine as long as I'm locally importing lib into my actual application repository. The moment I try to import lib into my repo using SPM's remote options, which is obviously the way to go for doing things with CI, it throws the following error:
invalidManifestFormat("'CursorPackage' is not a valid path for path-based dependencies; use relative or absolute path instead.")
This error persists whether I use CursorPackage or ./CursorPackage. Obviously I don't want to try to use an absolute path, because I'm on CI, so that would involve either hard-coding things or ingesting an environment variable somehow that contains PWD.
What am I missing? This seems like it should just work. Is this just a bug in SPM that I should be reporting to Apple?
This isn't intended to be possible. If you look at the 5th bullet in the Proposed Solution section of the local packages proposal (https://github.com/apple/swift-evolution/blob/main/proposals/0201-package-manager-local-dependencies.md) it says that it's not intended for a remote package to be allowed to depend on a local package.
I expect its because there's the possibility that you could have both a versioned package with a given name and a local package with the same name; if so how would SPM resolve the conflict?
It is unfortunate though since allowing this would allow for more options in how people organize their packages, I agree.
Swift Pacakage Manager allows a package manifest (Package.swift) file to specify build settings for targets.
As a security measure, some build settings can only be specified using "unsafeFlags" parameter. For example, specifying a framework search path outside the current directory using the -F build flag is considered "unsafe" because it could lead to code execution outside the package's own directory.
For packages downloaded from the internet, this could be considered an undesirable behavior. However, for locally-declared packages, this could be what we want to do.
However the design of SPM is such that any package that uses "unsafeFlags" cannot be depended on by another package.
Is there any override for this, for example, if we want to use unsafeFlags somewhere in a dependency structure of various locally-declared Swift packages?
Like, is there a setting we can supply for a package, framework, or app, so that it's allowed to depend on packages that use "unsafeFlags"?
Swift Package Manager allows unsafeOptions for dependencies specified by a commit hash. They're not allowed for versioned dependencies.
Example here.
Is there anyway I can just call into a define such as LIBFOO_DIRCLEAN, and just do what was implemented in the define?
Inside HOST_LIBFOO_INSTALL_CMDS, I copy files to the target directory, and would like the 'make package-dirclean' to delete what was copied into the target directory. 'make clean', would obviously do this(any many more), but that is much more than I want to do.
I see the following buildroot variables. LIBFOO_EXTRACT_CMDS, LIBFOO_CONFIGURE_CMDS, LIBFOO_BUILD_CMDS, HOST_LIBFOO_INSTALL_CMDS, LIBFOO_INSTALL_TARGET_CMDS, etc.
make foo-dirclean is a simple tool that just deletes the package build directory. In most cases, when the list of files installed by a package does not change over time (only files content changes) you can simply rebuild the package and the target directory will be rebuilt correctly.
If you want you can implement your own foo-myclean step that implements your own logic. However you must understand deleting files in the target directory is not supported by Buildroot and thus you are on your own.
For an application I am running, there is a run time error as it cannot find libwayland-client.so.0 shared object. How do I know which package provides it and where do I add it. I tried as shown below but it gave me a Nothing PROVIDES error.
CORE_IMAGE_EXTRA_INSTALL += "libwayland-client"
You don't typically work with single files when building Yocto images
In reverse order
You install packages to the image
You build packages by using a recipe
You find (or as a last resort write) recipes as part of layers.
Generally when something is missing you take the following steps:
Check the layerindex https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wayland It tells you that there is a recipe called wayland in layer openembedded-core
Add the layer in question. openembedded-core is already contained in Yocto's poky (directly under the name meta, just to confuse the newcomer...), so nothing to add in this example
Create the environment listing of the recipe in question, bitbake -e wayland >wayland.env
Check what packages the recipe in question creates grep ^PACKAGES= wayland.env. In this case it is easy because there is really only one package wayland (-debug, -dev etc. are special purpose that would not contain the library)
Add a package to the image by its package name. How to do that exactly depends on the image type you create. The variable name given in the question works for some images, but not all. Search for IMAGE_INSTALL in the manual https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html for other options.
Once you have built the recipe in question you can also check what files are contained in a package (In this case recipe name and package name are identical, but that is not always the case. Some recipes build more than one package suitable for installation, so obviously they need to use different names)
$ oe-pkgdata-util list-pkg-files wayland
wayland:
/usr/lib/libwayland-client.so.0
/usr/lib/libwayland-client.so.0.3.0
/usr/lib/libwayland-cursor.so.0
/usr/lib/libwayland-cursor.so.0.0.0
/usr/lib/libwayland-server.so.0
/usr/lib/libwayland-server.so.0.1.0
SQLAPI++ has an unusual feature where you set a string to tell it where to find the ODBC shared library. In my case this is libtdsodbc.so, and my application actually links that library at build time, but at runtime this is not enough for SQLAPI++ to work.
My code is:
SAConnection conn;
conn.setOption("ODBC.LIBS") = "libtdsodbc.so";
conn.Connect("SERVER=...", "", "", SA_ODBC_Client);
ODBC.LIBS is documented like this:
Forces SQLAPI++ Library to use specified ODBC manager library.
The above code works if you set LD_LIBRARY_PATH to a directory containing libtdsodbc.so. But if you don't, Connect() fails:
libtdsodbc.so: cannot open shared object file: No such file or directory
DBMS API Library 'libtdsodbc.so' loading fails
This library is a part of DBMS client installation, not SQLAPI++
Make sure DBMS client is installed and
this required library is available for dynamic loading
Linux/Unix:
1) The directories in the user's LD_LIBRARY_PATH environment variable
2) The list of libraries cached in /etc/ld.so.cache
3) /usr/lib, followed by /lib
It works again if you set ODBC.LIBS to a full path rather than just a filename. But how can the application know which path?
My application (outside of SQLAPI++) finds libtdsodbc.so via its RUNPATH which is set at build time. This path is not a system path like /usr/lib. I'd like to have SQLAPI++ use the same library which is loaded in the application at runtime.
One idea is for the application to inspect its own RUNPATH, search for libtdsobc.so, and use that path. But this requires quite a bit of fiddly code to basically reimplement what ld.so already does.
I don't want to bake the path into the executable at build time separately from RUNPATH, because I sometimes edit RUNPATH before deployment (and then I'd need to edit two things).
Ideally I would like to tell SQLAPI++ to just use the library which is already loaded. I can figure this path out by running lsof -p PID | grep libtdsodbc.so but running shell commands from within the executable is not a good solution (and again I would rather not reimplement lsof).
You could either use dl_iterate_phdr (the link also includes a sample code which prints out lib names) or manually parse /proc/self/maps.