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.
Added method concatenate_string_literals to CCompiler. Will concatenate
string literals.
Added keyword argument 'concatenate_string_literals' to Compiler.get_define.
If used will apply concatenate_string_literals to its return value.
Otherwise we can end up searching for the same library tens of times,
because pkg-config does not de-duplicate -lfoo args before returning
them.
We use -Wl,--start-group/end-group, so we do not need to worry about
ordering issues in static libraries.
This checks not only for existence, but also for usability of the
header, which means it does a full compilation and not just
pre-processing or __has_include.
Fixes https://github.com/mesonbuild/meson/issues/2246
* mesonbuild/compilers/c.py: Make the `find_library` method more generic by allowing the user to supply the `code` for compiling and linking.
* mesonbuild/compilers/fortran.py: Use the methods inherited from `Compiler` base class where appropriate. Also reuse `CComiler` methods where applicable. This should be sufficient to get various compiler/linker arguments as well as to compile and link Fortran programs. This was tested with `gfortran` compiler, and while the other compilers ought to work for simple cases, their methods are primarily inherited from the base `FortranCompiler` class.
* test cases/fortran/10 find library/gzip.f90: Fortran module with some basic Fortran wrapper interfaces to `gzopen`, `gzwrite`, and `gzclose` C `zlib` functions.
* test cases/fortran/10 find library/main.f90: Fortran program using the `gzip` Fortran interface module to write some data to a gzip file.
* test cases/fortran/10 find library/meson.build: Meson build file for this test case. This demonstrates the ability to link the Fortran program against an external library.
GCC does not print a warning or error for unknown options if the options
are to disable warnings. Therefore, when checking for options starting
'-Wno-', also check the opposite enabling option. This fixes the case
where e.g. -Wno-implicit-fallthrough is incorrectly reported as supported
by gcc 5.4. To avoid missed warnings when using combinations of flags, such
as in test case "112 has arg", we limit the checking of for the positive
option to where the negative option is checked alone.
This patch exploits the information residing in ltversion to set the
-compatibility_version and -current_version flags that are passed to the
linker on macOS.
The linkers currently do not support ninja compatible output of
dependencies used while linking. Try to guess which files will be used
while linking in python code and generate conservative dependencies to
ensure changes in linked libraries are detected.
This generates dependencies on the best match for static and shared
linking, but this should not be a problem, except for spurious
rebuilding when only one of them changes, which should not be a problem.
Also makes sure to ignore any libraries generated inside the build, to
keep the optimisation working where changes in a shared library only
cause relink if the symbols have changed as well.
This caching is only for a single run, so it doesn't help reconfigure.
However, it is useful for subproject setups where different subprojects
will run the same compiler checks.
The cache is also per compiler instance and is not used for functions
that want to read or run the outputted object file or binary.
For gst-build, this halves the number of compiler checks that are run
and reduces configuration time by 20%.
Copy the algorithm used by autoconf.
It computes the upper and lower limits by starting at [-1,1] and
multiply by 2 at each iteration. This is even faster for small numbers
(the common case), for example it finds value 0 in just 2 compilations
where old algorithm would check for 1024, 512, ..., 0.
Recent versions of systemd (starting with v238) started to check for the
existence of the statx structure using the cc.sizeof() operation. The cc
compiler implementation fails to detect this structure because it's size
limit is 128, meaning it will fail for any type larger than 128 bytes in
the following way during cross-compilation checks:
meson.build:10:2: ERROR: Cross-compile check overflowed
Increase the size limit for data types to 1024 bytes, which should give
plenty of room for even large data structures. This is obviously not
guaranteed to be an upper bound, but given the binary search algorithm
implemented in the cross-compile check, raising the limit too high may
significantly increase the time required for this check on smaller data
types.
Signed-off-by: Thierry Reding <treding@nvidia.com>
- Fixing flake8 error in compilers.py - [E124] closing bracket does not match visual indentation
- Updating ARMCCompiler constructor in c.py to raise error as per comments
A hard error makes this feature useless in most cases since a static
library usually won't be found for every library, particularly system
libraries like -lm. Instead, warn so the user can provide the static
library if they wish.
This feature will be expanded and made more extensible and more usable
in the future.
Closes https://github.com/mesonbuild/meson/issues/2785
After PR #2662, running test case common/125 shared module/ on Cygwin gets
me:
$ ninja -C _build
ninja: Entering directory `_build'
[7/7] Linking target prog.exe.
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: warning: --export-dynamic is not supported for PE+ targets, did you mean --export-all-symbols?
Also, fix doc for correct version of first apperance.
Future work: Notwithstanding the hint that ld gives, these options are not
equivalent, and it's not clear we should be using it here:
--export-all-symbols is the default behaviour, and if the exports are
restricted by explicit annotations or a .def file, this option might be
overriding that...
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
has_argument and other similar methods of compiler objects only support
checking compiler flags. If they are used to check linker flags, the
results are very likely to be wrong and developers should be warned.
See issue #2762
Adds full_version to class Compiler. If set full_version will be printed
additionally.
Added support for CCompiler and CPPCompiler
Added support for gcc/g++, clang/clang++, icc.
We can't know if the .lib is a static or import library, but that's
a problem in general too. The only way to figure out if a specific
file is an import or a static library is to dump its symbols and check
if it starts with __imp or not.
Even then, some libs are hybrid import and static, i.e., they contain
references to DLLs for some symbols and also provide implementations
for other symbols so this is a difficult problem.
Closes https://github.com/mesonbuild/meson/issues/2659