| Age | Commit message (Collapse) | Author |
|---|
|
While investigating a reproducible problem with a binary compiled with
Meson, it was notice that the RPATH entry was never removed.
By comparing the binary from 2 different build system it was observed
that altough the RPATH entry was removed (verified by the readelf -d
command) the actual path was still present causing 2 different binary.
Going deeper in the Meson build process, it was discovered that
remove_rpath_entry only deletes the entry in the '.dynamic' section but
never actually 'clean' (or better say zero-out) the path from the
.dynstr section producing binary dependendt of the build system.
To address this, introduce a new helper to to zero-out the entry from
the .dynstr section permitting to produce REAL reproducible binary.
Additional logic was needed to handle GCC linker optimization for dynstr
table where the rpath string might be reused for other dym function
string. The setion that is actually removed is filled with 'X' following
patchelf behaviour.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
|
|
|
Duplicated -delete_rpath arguments will cause macOS's install_name_tool
failed.
|
|
Fixes regression in commit 78e9009ff9d36925e04f329f9082841002ddd848.
new_rpath is only set when install_rpath appears in meson.build.
Before this commit, we treated new_rpath as a single string to pass to
-add_rpath. This worked as long as new_rpath had a single rpath in it,
though for ELF we explicitly supported multiple rpaths separated with
":" (as binutils ld is quite happy with that too).
install_name_tool does not support paths with colons in it:
```
21:12 <awilfox> Load command 19 cmd LC_RPATH cmdsize 40 path /bar:/baz:/eli:/ldap (offset 12)
21:12 <awilfox> Load command 20 cmd LC_RPATH cmdsize 24 path /foo (offset 12)
21:14 <awilfox> so the result is: do not use colons
```
After commit 78e9009ff9d36925e04f329f9082841002ddd848, we simply ended
up with one load command for LC_RPATH per char in new_rpath, which was
wrong in every possible case.
What we actually need to do is pass every distinct rpath as a separate
`-add_rpath` argument, so we split it on the colons instead. We do the
same splitting to ensure proper diff'ability for ELF anyways...
Fixes #13355
|
|
This somewhat aligns "darwin" (Mach-O) with how ELF RPATHs are treated.
Instead of blindly removing all RPATHs, only remove the ones that are in
the rpath_dirs_to_remove set. This way, RPATHs that were added by the
toolchain or user are left untouched.
It is important not to remove RPATHs as they may be vital for the
executable at runtime. Issues #12045 and #12288 are examples of this.
Issue: https://github.com/mesonbuild/meson/issues/12045
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
The former is unix-only, which complains when running on the Windows
platform -- even though this code is in a unix-specific branch.
But per the docs:
> As of Python 3.3, this is equivalent to os.chmod(fd, mode).
So we can just use the identical function that is available in more
places.
|
|
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
|
|
Avoids non-actionable output when installing a jar:
inflated: META-INF/MANIFEST.MF
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
|
|
|
|
I assume there's no real reason this cannot happen, perhaps if the meson
source directory has one. So we should use Popen_safe for safety
reasons.
|
|
This does force a number of uses of `# pylint: disable` comments, but it
also finds a couple of useless global uses and one place (in the
previous commit) that an easy refactor removes the use of global. Global
is a code smell, so forcing adding a comment to disable helps force
developers to really consider if what they're doing is a good idea.
|
|
This finds a bunch of places where we can do more efficient string
splitting.
|
|
The messages are not useful unless we know what file they are about.
|
|
When installing with 'meson install --quiet' I'd get the following output:
This file does not have an rpath.
This file does not have a runpath.
(It turns out that of the couple hundred of binaries that are installed,
this message was generated for /usr/lib/systemd/boot/efi/linuxx64.elf.stub.)
There doesn't seem to be any good reason for this output by default. But those
functions can still be used for debugging. Under a debugger, returning the
string is just as useful as printing it, but more flexible. So let's suppress
printing of anything by default, but keep the extractor functions.
The code was somewhat inconsistent wrt. to when .decode() was done. But it
seems that we'll get can expect a decodable text string in all cases, so
just call .decode() everywhere, because it's nicer to print decoded strings.
|
|
|
|
|
|
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
|
|
|
|
If the installed files don't have suitable file permissions depfixer
will fail to process it. Temporarily lax file permissions to work around
this.
|
|
It's only used for doing an `if x in container` check, which will be
faster with a set, and the only caller already has a set, so avoid
we can avoid a type conversion as well.
|
|
Fixes: #8115
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #4027
|
|
Generated headers, PDB files, import libraries, etc.
Speed-up in gst-build on Windows:
```
meson install
before: 5.4 seconds
after: 5.1 seconds
meson install --only-changed
before: 2.7 seconds
after: 1.6 seconds
```
|
|
This gives a significant speedup in large projects such as gst-build
since now we only search for the tool once. Speed-up on Windows:
```
meson install:
before: 15.3 seconds
after: 5.4 seconds
meson install --only-changed:
before: 11.6 seconds
after: 2.7 seconds
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).
However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.
We now change that install name to point to the absolute path to each
built library after installation.
Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077
With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.
|
|
The install name is used by consumers of the library to find the
library at runtime. If it's @rpath/libfoo.dylib, all consumers must
manually add the library path to RPATH, which is not what people
expect.
Almost everyone sets the library install name as the full path to the
library, and this is done at install time with install_name_tool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
