Pkg ��� ���������� linux

pkg-config(1) — Linux man page

pkg-config — Return metainformation about installed libraries

Synopsis

pkg-config [—modversion] [—help] [—print-errors] [—silence-errors] [—cflags] [—libs] [—libs-only-L] [—libs-only-l] [—cflags-only-I] [—variable=VARIABLENAME] [—define-variable=VARIABLENAME=VARIABLEVALUE] [—uninstalled] [—exists] [—atleast-version=VERSION] [—exact-version=VERSION] [—max-version=VERSION] [LIBRARIES. ]

Description

The pkg-config program is used to retrieve information about installed libraries in the system. It is typically used to compile and link against one or more libraries. Here is a typical usage scenario in a Makefile: cc program.c ‘pkg-config —cflags —libs gnomeui’ pkg-config retrieves information about packages from special metadata files. These files are named after the package, with the extension .pc. By default, pkg-config looks in the directory prefix/lib/pkgconfig for these files; it will also look in the colon-separated (on Windows, semicolon-separated) list of directories specified by the PKG_CONFIG_PATH environment variable.

The package name specified on the pkg-config command line is defined to be the name of the metadata file, minus the .pc extension. If a library can install multiple versions simultaneously, it must give each version its own name (for example, GTK 1.2 might have the package name «gtk+» while GTK 2.0 has «gtk+-2.0»).

Options

The following options are supported: —modversion Requests that the version information of the libraries specified on the command line be displayed. If pkg-config can find all the libraries on the command line, each library’s version string is printed to stdout, one version per line. In this case pkg-config exits successfully. If one or more libraries is unknown, pkg-config exits with a nonzero code, and the contents of stdout are undefined. —help

Displays a help message and terminates. —print-errors If one or more of the modules on the command line, or their dependencies, are not found, or if an error occurs in parsing a .pc file, then this option will cause errors explaining the problem to be printed. With «predicate» options such as «—exists» pkg-config runs silently by default, because it’s usually used in scripts that want to control what’s output. This option can be used alone (to just print errors encountered locating modules on the command line) or with other options. The PKG_CONFIG_DEBUG_SPEW environment variable overrides this option. —silence-errors If one or more of the modules on the command line, or their dependencies, are not found, or if an error occurs in parsing a a .pc file, then this option will keep errors explaining the problem from being printed. With «predicate» options such as «—exists» pkg-config runs silently by default, because it’s usually used in scripts that want to control what’s output. So this option is only useful with options such as «—cflags» or «—modversion» that print errors by default. The PKG_CONFIG_DEBUG_SPEW environment variable overrides this option. —errors-to-stdout If printing errors, print them to stdout rather than the default stderr The following options are used to compile and link programs: —cflags This prints pre-processor and compile flags required to compile the packages on the command line, including flags for all their dependencies. Flags are «compressed» so that each identical flag appears only once. pkg-config exits with a nonzero code if it can’t find metadata for one or more of the packages on the command line. —libs

This option is identical to «—cflags», only it prints the link flags. As with «—cflags», duplicate flags are merged (maintaining proper ordering), and flags for dependencies are included in the output. —libs-only-L This prints the -L/-R part of «—libs». That is, it defines the library search path but doesn’t specify which libraries to link with. —libs-only-l This prints the -l part of «—libs» for the libraries specified on the command line. Note that the union of «—libs-only-l» and «—libs-only-L» may be smaller than «—libs», due to flags such as -rdynamic. —variable=VARIABLENAME This returns the value of a variable defined in a package’s .pc file. Most packages define the variable «prefix», for example, so you can say: —define-variable=VARIABLENAME=VARIABLEVALUE This sets a global value for a variable, overriding the value in any .pc files. Most packages define the variable «prefix», for example, so you can say: —uninstalled Normally if you request the package «foo» and the package «foo-uninstalled» exists, pkg-config will prefer the «-uninstalled» variant. This allows compilation/linking against uninstalled packages. If you specify the «—uninstalled» option, pkg-config will return successfully if any «-uninstalled» packages are being used, and return failure (false) otherwise. (The «PKG_CONFIG_DISABLE_UNINSTALLED» environment variable keeps pkg-config from implicitly choosing «-uninstalled» packages, so if that variable is set, they will only have been used if you pass a name like «foo-uninstalled» on the command line explicitly.) —exists —atleast-version=VERSION —exact-version=VERSION —max-version=VERSION These options test whether the package or list of packages on the command line are known to pkg-config, and optionally whether the version number of a package meets certain contraints. If all packages exist and meet the specified version constraints, pkg-config exits successfully. Otherwise it exits unsuccessfully.

Rather than using the version-test options, you can simply give a version constraint after each package name, for example: Remember to use —print-errors if you want error messages. —msvc-syntax This option is available only on Windows. It causes pkg-config to output -l and -L flags in the form recognized by the Microsoft Visual C++ command-line compiler, cl. Specifically, instead of -Lx:/some/path it prints /libpath:x/some/path, and instead of -lfoo it prints foo.lib. Note that the —libs output consists of flags for the linker, and should be placed on the cl command line after a /link switch. —dont-define-prefix This option is available only on Windows. It prevents pkg-config from automatically trying to override the value of the variable «prefix» in each .pc file. —prefix-variable=PREFIX Also this option is available only on Windows. It sets the name of the variable that pkg-config automatically sets as described above. —static Output libraries suitable for static linking. That means including any private libraries in the output. This relies on proper tagging in the .pc files, else a too large number of libraries will ordinarily be output.

Environment Variables

PKG_CONFIG_PATH A colon-separated (on Windows, semicolon-separated) list of directories to search for .pc files. The default directory will always be searched after searching the path; the default is libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir where pkg-config and datadir is the datadir where pkg-config was installed. PKG_CONFIG_DEBUG_SPEW If set, causes pkg-config to print all kinds of debugging information and report all errors. PKG_CONFIG_TOP_BUILD_DIR A value to set for the magic variable pc_top_builddir which may appear in .pc files. If the environment variable is not set, the default value ‘$(top_builddir)’ will be used. This variable should refer to the top builddir of the Makefile where the compile/link flags reported by pkg-config will be used. This only matters when compiling/linking against a package that hasn’t yet been installed. PKG_CONFIG_DISABLE_UNINSTALLED Normally if you request the package «foo» and the package «foo-uninstalled» exists, pkg-config will prefer the «-uninstalled» variant. This allows compilation/linking against uninstalled packages. If this environment variable is set, it disables said behavior. PKG_CONFIG_ALLOW_SYSTEM_CFLAGS Don’t strip -I/usr/include out of cflags. PKG_CONFIG_ALLOW_SYSTEM_LIBS Don’t strip -L/usr/lib out of libs PKG_CONFIG_SYSROOT_DIR Modify -I and -L to use the directories located in target sysroot. this option is usefull when crosscompiling package that use pkg-config to determine CFLAGS anf LDFLAGS. -I and -L are modified to point to the new system root. this means that a -I/usr/include/libfoo will become -I/var/target/usr/include/libfoo with a PKG_CONFIG_SYSROOT_DIR equal to /var/target (same rule apply to -L) PKG_CONFIG_LIBDIR Replaces the default pkg-config search directory.

Windows Specialities

If a .pc file is found in a directory that matches the usual conventions (i.e., ends with \lib\pkgconfig), the prefix for that package is assumed to be the grandparent of the directory where the file was found, and the prefix variable is overridden for that file accordingly.

In addition to the PKG_CONFIG_PATH environment variable, the Registry keys HKEY_CURRENT_USER\Software\pkgconfig\PKG_CONFIG_PATH and HKEY_LOCAL_MACHINE\Software\pkgconfig\PKG_CONFIG_PATH can be used to specify directories to search for .pc files. Each (string) value in these keys is treated as a directory where to look for .pc files.

Autoconf Macros

PKG_CHECK_MODULES(VARIABLE-PREFIX,MODULES[,ACTION-IF-FOUND,[ACTION-IF-NOT-FOUND]]) The macro PKG_CHECK_MODULES can be used in configure.ac to check whether modules exist. A typical usage would be: This would result in MYSTUFF_LIBS and MYSTUFF_CFLAGS substitution variables, set to the libs and cflags for the given module list. If a module is missing or has the wrong version, by default configure will abort with a message. To replace the default action, specify an ACTION-IF-NOT-FOUND. PKG_CHECK_MODULES will not print any error messages if you specify your own ACTION-IF-NOT-FOUND. However, it will set the variable MYSTUFF_PKG_ERRORS, which you can use to display what went wrong.

Note that if there is a possibility the first call to PKG_CHECK_MODULES might not happen, you should be sure to include an explicit call to PKG_PROG_PKG_CONFIG in your configure.ac

Defines the PKG_CONFIG variable to the best pkg-config available, useful if you need pkg-config but don’t want to use PKG_CHECK_MODULES.

PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])

Check to see whether a particular set of modules exists. Similar to PKG_CHECK_MODULES(), but does not set variables or print errors.

Similar to PKG_CHECK_MODULES, make sure that the first instance of this or PKG_CHECK_MODULES is called, or make sure to call PKG_CHECK_EXISTS manually

Metadata File Syntax

To add a library to the set of packages pkg-config knows about, simply install a .pc file. You should install this file to libdir/pkgconfig.

Here is an example file: You would normally generate the file using configure, of course, so that the prefix, etc. are set to the proper values.

Files have two kinds of line: keyword lines start with a keyword plus a colon, and variable definitions start with an alphanumeric string plus an equals sign. Keywords are defined in advance and have special meaning to pkg-config; variables do not, you can have any variables that you wish (however, users may expect to retrieve the usual directory name variables).

Note that variable references are written «$«; you can escape literal «$<" as "$$<". Name:

This field should be a human-readable name for the package. Note that it is not the name passed as an argument to pkg-config. Description: This should be a brief description of the package URL:

An URL where people can get more information about and download the package Version: This should be the most-specific-possible package version string. Requires: This is a comma-separated list of packages that are required by your package. Flags from dependent packages will be merged in to the flags reported for your package. Optionally, you can specify the version of the required package (using the operators =, , >=, Conflicts: This optional line allows pkg-config to perform additional sanity checks, primarily to detect broken user installations. The syntax is the same as Requires: except that you can list the same package more than once here, for example «foobar = 1.2.3, foobar = 1.2.5, foobar >= 1.3», if you have reason to do so. If a version isn’t specified, then your package conflicts with all versions of the mentioned package. If a user tries to use your package and a conflicting package at the same time, then pkg-config will complain. Libs:

This line should give the link flags specific to your package. Don’t add any flags for required packages; pkg-config will add those automatically. Libs.private: This line should list any private libraries in use. Private libraries are libraries which are not exposed through your library, but are needed in the case of static linking. Cflags: This line should list the compile flags specific to your package. Don’t add any flags for required packages; pkg-config will add those automatically.

Author

pkg-config was written by James Henstridge, rewritten by Martijn van Beers, and rewritten again by Havoc Pennington. Tim Janik, Owen Taylor, and Raja Harinath submitted suggestions and some code. gnome-config was written by Miguel de Icaza, Raja Harinath and various hackers in the GNOME team. It was inspired by Owen Taylor’s gtk-config program.

pkg-config does not handle mixing of parameters with and without = well. Stick with one.

Источник

Pkg ��� ���������� linux

Disclaimer: pkg was created for use within containers and is not intended for use in serverless environments. For those using Vercel, this means that there is no requirement to use pkg in your projects as the benefits it provides are not applicable to the platform.

This command line interface enables you to package your Node.js project into an executable that can be run even on devices without Node.js installed.

Use Cases

• Make a commercial version of your application without sources
• Make a demo/evaluation/trial version of your app without sources
• Instantly make executables for other platforms (cross-compilation)
• Make some kind of self-extracting archive or installer
• No need to install Node.js and npm to run the packaged application
• No need to download hundreds of files via npm install to deploy your application. Deploy it as a single file
• Put your assets inside the executable to make it even more portable
• Test your app against new Node.js version without installing it

Usage

After installing it, run pkg —help without arguments to see list of options.

The entrypoint of your project is a mandatory CLI argument. It may be:

• Path to entry file. Suppose it is /path/app.js , then packaged app will work the same way as node /path/app.js
• Path to package.json . Pkg will follow bin property of the specified package.json and use it as entry file.
• Path to directory. Pkg will look for package.json in the specified directory. See above.

Targets

pkg can generate executables for several target machines at a time. You can specify a comma-separated list of targets via —targets option. A canonical target consists of 3 elements, separated by dashes, for example node12-macos-x64 or node14-linux-arm64 :

• nodeRange (node8), node10, node12, node14, node16 or latest
• platform alpine, linux, linuxstatic, win, macos, (freebsd)
• arch x64, arm64, (armv6, armv7)

(element) is unsupported, but you may try to compile yourself.

You may omit any element (and specify just node14 for example). The omitted elements will be taken from current platform or system-wide Node.js installation (its version and arch). There is also an alias host , that means that all 3 elements are taken from current platform/Node.js. By default targets are linux,macos,win for current Node.js version and arch.

If you want to generate executable for different architectures, note that by default pkg has to run the executable of the target arch to generate bytecodes:

• Linux: configure binfmt with QEMU.
• macOS: possible to build x64 on arm64 with Rosetta 2 but not opposite.
• Windows: possible to build x64 on arm64 with x64 emulation but not opposite.
• or, disable bytecode generation with —no-bytecode —public-packages «*» —public .

macos-arm64 is experimental. Be careful about the mandatory code signing requirement. The final executable has to be signed (ad-hoc signature is sufficient) with codesign utility of macOS (or ldid utility on Linux). Otherwise, the executable will be killed by kernel and the end-user has no way to permit it to run at all. pkg tries to ad-hoc sign the final executable. If necessary, you can replace this signature with your own trusted Apple Developer ID.

To be able to generate executables for all supported architectures and platforms, run pkg on a Linux host with binfmt ( QEMU emulation) configured and ldid installed.

Config

During packaging process pkg parses your sources, detects calls to require , traverses the dependencies of your project and includes them into executable. In most cases you don’t need to specify anything manually.

However your code may have require(variable) calls (so called non-literal argument to require ) or use non-javascript files (for example views, css, images etc).

Such cases are not handled by pkg . So you must specify the files — scripts and assets — manually in pkg property of your package.json file.

The above example will include everything in assets/ and every .js file in build/ , build only for node14-linux-arm64 , and place the executable inside dist/ .

You may also specify arrays of globs:

Just be sure to call pkg package.json or pkg . to make use of package.json configuration.

Scripts

scripts is a glob or list of globs. Files specified as scripts will be compiled using v8::ScriptCompiler and placed into executable without sources. They must conform to the JS standards of those Node.js versions you target (see Targets), i.e. be already transpiled.

Assets

assets is a glob or list of globs. Files specified as assets will be packaged into executable as raw content without modifications. Javascript files may also be specified as assets . Their sources will not be stripped as it improves execution performance of the files and simplifies debugging.

Options

Node.js application can be called with runtime options (belonging to Node.js or V8). To list them type node —help or node —v8-options .

You can «bake» these runtime options into packaged application. The app will always run with the options turned on. Just remove — from option name.

You can specify multiple options by joining them in a single string, comma ( , ) separated:

Output

You may specify —output if you create only one executable or —out-path to place executables for multiple targets.

Debug

Pass —debug to pkg to get a log of packaging process. If you have issues with some particular file (seems not packaged into executable), it may be useful to look through the log.

Bytecode (reproducibility)

By default, your source code is precompiled to v8 bytecode before being written to the output file. To disable this feature, pass —no-bytecode to pkg .

Why would you want to do this?

If you need a reproducible build process where your executable hashes (e.g. md5, sha1, sha256, etc.) are the same value between builds. Because compiling bytecode is not deterministic (see here or here) it results in executables with differing hashed values. Disabling bytecode compilation allows a given input to always have the same output.

Why would you NOT want to do this?

While compiling to bytecode does not make your source code 100% secure, it does add a small layer of security/privacy/obscurity to your source code. Turning off bytecode compilation causes the raw source code to be written directly to the executable file. If you’re on *nix machine and would like an example, run pkg with the —no-bytecode flag, and use the GNU strings tool on the output. You then should be able to grep your source code.

Other considerations

Specifying —no-bytecode will fail if there are any packages in your project that aren’t explicitly marked as public by the license in their package.json . By default, pkg will check the license of each package and make sure that stuff that isn’t meant for the public will only be included as bytecode.

If you do require building pkg binaries for other architectures and/or depend on a package with a broken license in its package.json , you can override this behaviour by either explicitly whitelisting packages to be public using —public-packages «packageA,packageB» or setting all packages to public using —public-packages «*»

Build

pkg has so called «base binaries» — they are actually same node executables but with some patches applied. They are used as a base for every executable pkg creates. pkg downloads precompiled base binaries before packaging your application. If you prefer to compile base binaries from source instead of downloading them, you may pass —build option to pkg . First ensure your computer meets the requirements to compile original Node.js: BUILDING.md

See pkg-fetch for more info.

Compression

Pass —compress Brotli or —compress GZip to pkg to compress further the content of the files store in the exectable.

This option can reduce the size of the embedded file system by up to 60%.

The startup time of the application might be reduced slightly.

-C can be used as a shortcut for —compress .

Environment

Var	Description
PKG_CACHE_PATH	Used to specify a custom path for node binaries cache folder. Default is

/.pkg-cache PKG_IGNORE_TAG Allows to ignore additional folder created on PKG_CACHE_PATH matching pkg-fetch version MAKE_JOB_COUNT Allow configuring number of processes used for compiling

Usage of packaged app

Command line call to packaged app ./app a b is equivalent to node app.js a b

Snapshot filesystem

During packaging process pkg collects project files and places them into executable. It is called a snapshot. At run time the packaged application has access to snapshot filesystem where all that files reside.

Packaged files have /snapshot/ prefix in their paths (or C:\snapshot\ in Windows). If you used pkg /path/app.js command line, then __filename value will be likely /snapshot/path/app.js at run time. __dirname will be /snapshot/path as well. Here is the comparison table of path-related values:

value	with node	packaged	comments
__filename	/project/app.js	/snapshot/project/app.js
__dirname	/project	/snapshot/project
process.cwd()	/project	/deploy	suppose the app is called .
process.execPath	/usr/bin/nodejs	/deploy/app-x64	app-x64 and run in /deploy
process.argv[0]	/usr/bin/nodejs	/deploy/app-x64
process.argv[1]	/project/app.js	/snapshot/project/app.js
process.pkg.entrypoint	undefined	/snapshot/project/app.js
process.pkg.defaultEntrypoint	undefined	/snapshot/project/app.js
require.main.filename	/project/app.js	/snapshot/project/app.js

Hence, in order to make use of a file collected at packaging time ( require a javascript file or serve an asset) you should take __filename , __dirname , process.pkg.defaultEntrypoint or require.main.filename as a base for your path calculations. For javascript files you can just require or require.resolve because they use current __dirname by default. For assets use path.join(__dirname, ‘../path/to/asset’) . Learn more about path.join in Detecting assets in source code.

On the other hand, in order to access real file system at run time (pick up a user’s external javascript plugin, json configuration or even get a list of user’s directory) you should take process.cwd() or path.dirname(process.execPath) .

Detecting assets in source code

When pkg encounters path.join(__dirname, ‘../path/to/asset’) , it automatically packages the file specified as an asset. See Assets. Pay attention that path.join must have two arguments and the last one must be a string literal.

This way you may even avoid creating pkg config for your project.

Native addons

Native addons ( .node files) use is supported. When pkg encounters a .node file in a require call, it will package this like an asset. In some cases (like with the bindings package), the module path is generated dynamicaly and pkg won’t be able to detect it. In this case, you should add the .node file directly in the assets field in package.json .

The way Node.js requires native addon is different from a classic JS file. It needs to have a file on disk to load it, but pkg only generates one file. To circumvent this, pkg will create a temporary file on the disk. These files will stay on the disk after the process has exited and will be used again on the next process launch.

When a package, that contains a native module, is being installed, the native module is compiled against current system-wide Node.js version. Then, when you compile your project with pkg , pay attention to —target option. You should specify the same Node.js version as your system-wide Node.js to make compiled executable compatible with .node files.

Note that fully static Node binaries are not capable of loading native bindings, so you may not use Node bindings with linuxstatic .

exec(args) takes an array of command line arguments and returns a promise. For example:

Troubleshooting

Error: ENOENT: no such file or directory, uv_chdir

This error can be caused by deleting the directory the application is run from. Or, generally, deleting process.cwd() directory when the application is running.

Error: ERR_INSPECTOR_NOT_AVAILABLE

This error can be caused by using NODE_OPTIONS variable to force to run node with the debug mode enabled. Debugging options are disallowed , as pkg executables are usually used for production environments. If you do need to use inspector, you can build a debuggable Node.js yourself.

Error: require(. ).internalModuleStat is not a function

This error can be caused by using NODE_OPTIONS variable with some bootstrap or node options causing conflicts with pkg. Some IDEs, such as VS Code, may add this env variable automatically.

You could check on Unix systems (Linux/macOS) in bash :

Advanced

exploring virtual file system embedded in debug mode

When you are using the —debug flag when building your executable, pkg add the ability to display the content of the virtual file system and the symlink table on the console, when the application starts, providing that the environement variable DEBUG_PKG is set. This feature can be useful to inspect if symlinks are correctly handled, and check that all the required files for your application are properly incorporated to the final executable.

Note: make sure not to use —debug flag in production.

Источник