IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Unfortunately, many generated configure files do not accept this option,
failing build with the following diagnostics:
configure: error: unrecognized option: `--runstatedir=/var/run'
This reverts commit 9bed7dcbad.
Man gcc: "Use -flto=auto to use GNU make's job server, if available, or
otherwise fall back to autodetection of the number of CPU threads
present in your system."
Update %configure macro to pass --runstatedir=%_runtimedir
option to configure.
Update %makeinstall macro to pass runstatedir=%buildroot%_runtimedir
argument to make.
To opt out:
%define optflags_lto %nil
To compile libs add `-ffat-lto-objects' like this:
%define optflags_lto %optflags_lto -ffat-lto-objects
Do not use `-ffat-lto-objects' for anything except exported libs as it
doubles compile time.
This macro offers %{_smp_mflags}, but without the -j prefix, to signify
the configured number of processor cores to use.
We can use this to pass that number to utilities that do not understand
the -j number syntax, for example:
`cmake --build %_cmake__builddir --verbose --parallel %_smp_build_ncpus'
The name was picked to be compatible with RH:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/platform.in#L51
We preserve ALT semantics though.
`strip' is called by `install -s` that could occur in unpatched
Makefiles, breaking debuginfo generation.
Try to catch `install` invocations via:
- %__install macro used in `make INSTALL=`.
- Prefix PATH with `/usr/libexec/rpm-build` with install and strip
wrappers.
Suggested-by: Dmitry V. Levin <ldv@altlinux.org>
Reviewed-by: Dmitry V. Levin <ldv@altlinux.org>
This removes %post_ldconfig, %post_ldconfig_lib, %post_ldconfig_sys,
and %postun_ldconfig macros which were marked as obsolete by commit
da3de4082f back in 2008.
Terminate build if stripped ELF files are found. Usage:
%define _stripped_files_terminate_build 1
Formatting suggestions by Dmitry V. Levin <ldv@altlinux.org>.
FCFLAGS is modern replacement of FFLAGS for gfortran.
Details can be found in [1].
Modern Fortran applications use FCFLAGS instead of FFLAGS, so we have
them built without platform-specific and general optimizations.
As an example one may look how libgfortran is being built within gcc-9:
libgfortran/Makefile.in uses only FCFLAGS, not FFLAGS and mary other
applications follow.
[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Fortran-Compiler.html
It's always annoying when important information such as compilation
options used for build is not available in build logs just because
silent build rules are enabled by default.
Fix this for the case of build rules generated by configure
by disabling silent rules.
%EVR was introduced to be used in spec-files for intersubpackage
(strict) dependencies.
What if we write (when substituting %%EVR) E:V-R:D into dependencies
instead of the previously written E:V-R? Will the interpretation of
these dependencies by rpm change (when installing packages) in a good
or bad way in any cases?
The "dependencies" can be Requires, Conflicts, Obsoletes.
rpm-build already produces packages which include disttags (D), and
Provides in the form of E:V-R:D, and strict intersubpackage
dependencies of such form (Requires; generated automatically).
Intersubpackage Requires in the form "< %EVR" or "> %EVR" don't make
sense. So, the interesting cases this change can affect are:
* Conflicts of the form "< %EVR" or "> %EVR" or "= %EVR" (the last one
must be quite rare);
* Obsoletes of the form "< %EVR" ("= %EVR" makes little sense;
"> %EVR" looks strange because it's about obsoleting packages from future).
The rpm program can be "new" (which knows how to compare E:V-R:Ds with
disttags; since 4.13.0.1-alt5) or "old" (does not yet know it;
4.13.0.1-alt4 or earlier).
(rpm-build already produces "new" packages, i.e., with disttags.)
The "new" rpm program is considered to be the correct reference way to
treat disttags. According to it, the presence of a disttag in a < or >
dependency cannot affect its interpretation (whether it is satisfied
by another package). Adding a disttag to a = dependency would simply
make it more strict (and that's what rpm-build already does under the
hood for intersubpackage deps). So, E:V-R:D deps are OK for the "new"
rpm.
So, what about about the "old" rpm?
Let's pay attention to the cases where the "old" rpm behaves
differently from the "new" rpm.
Such differences can be demonstrated by running
rpminstall-tests-1.0-alt2.M70P.1 in a system with an "old" rpm and a
"new" rpm-build (that can produce packages with disttags).
Here are the interesting failed test cases without disttag in the dependencies
(like before the change made by this commit), i.e. with dependencies
in the form E:V-R written in Conflicts or Obsoletes:
* installable_dummyDisttag_with_conflGreaterEpoch (and similar ones)
$ rpm -qp RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1:zzz+777.66
$ rpm -qp RPMS/conflGreaterEpoch/noarch/conflGreaterEpoch-1-alt1.noarch.rpm --conflicts
dummy > 0:1-alt1
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/conflGreaterEpoch/noarch/conflGreaterEpoch-1-alt1.noarch.rpm
error: Failed dependencies:
dummy > 0:1-alt1 conflicts with conflGreaterEpoch-1-alt1.noarch
NOT OK (ALT#35930): this form of Conflicts is used to ensure that no
subpackages from different releases/builds get installed together.
* noninstallable_dummyDisttag_with_conflEqualEpoch (and similar ones)
$ rpm -qp RPMS/conflEqualEpoch/noarch/conflEqualEpoch-1-alt1.noarch.rpm --conflicts
dummy = 0:1-alt1
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/conflEqualEpoch/noarch/conflEqualEpoch-1-alt1.noarch.rpm
succeeds
NOT OK: this form of conflicts could be used to declare conflicting subpackages.
Here are the interesting failed test cases with disttag in the
dependencies (like after the change made by this commit), i.e. with
dependencies in the form E:V-R:D written in Conflicts or Obsoletes:
* installable_dummy_with_conflLessEpochDisttag (and similar ones),
$ rpm -qp RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1
$ rpm -qp RPMS/conflLessEpochDisttag/noarch/conflLessEpochDisttag-1-alt1.noarch.rpm --conflicts
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/conflLessEpochDisttag/noarch/conflLessEpochDisttag-1-alt1.noarch.rpm
error: Failed dependencies:
dummy < 0:1-alt1:zzz+777.66 conflicts with conflLessEpochDisttag-1-alt1.noarch
OK: dummy-1-alt1.noarch.rpm is from another build (if built with the
"new" rpm-build, it would include the disttag in Provides). This form
of Conflicts is used to ensure that no subpackages from different
releases/builds get installed together. The difference in behavior
with the "new" rpm is explained by that the "new" rpm cannot
(unfortunately) detect this subtle mismatch.
* nonobsoleted_dummy_with_obsolLessEpochDisttag (and similar ones)
(like the previous case)
$ rpm -qp RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm --obsoletes
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm
$ rpm -q dummy
package dummy is not installed
OK
* nonobsoleted_dummyDisttag_with_obsolLessEpochDisttag (and similar ones)
$ rpm -qp RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1:zzz+777.66
$ rpm -qp RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm --obsoletes
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm
$ rpm -q dummy
package dummy is not installed
NOT OK, but very improbable (the real name of the subpackage must be
the same as the obsoleted name of an older package, but the obsoleting
package is a different subpackage; so, it's improbable that one keeps
the old name of a subpackage, but wants to obsolete it with another
subpackage).
So, introducing this change to the %EVR value would make the new
packages be treated better by the "old" rpm; even the treatment in the
cases where the behavior is different from the behavior of the "new"
rpm is good (except for one improbable case).
Previously one who wanted to use only suffix from %_lib macro (without
'lib' prefix) had to either strip it with shell or try to guess it
from %_lib macro.
New macros allow to simplify library suffix logics in spec files:
* %_libsuff is always defined (to %nil on targets where %_lib = lib);
* %_is_libsuff is defined only on those targets where suffix
is not empty (it is useful for %{?...} expressions).
nproc(1) based approach has two advantages over /proc/stat based
calculations. Firstly, nproc(1) uses sched_getaffinity(2) and therefore
is not affected by /proc availability. Secondly, nproc(1) outputs
the number of processors actually available which may be less than
the number of online processors.
nproc(1) was introduced in coreutils-8.1.
glibc-2.26~154 changed behaviour of "getconf _NPROCESSORS_ONLN":
it now returns 2 instead of 1 when /proc is not mounted.
Change %_smp_mflags to use %__nprocs that is set to 1 when /proc
is not available.
gcc -frecord-gcc-switches adds .GCC.command.line section to each
generated ELF file. These sections have the same type (PROGBITS) and
flags (MERGE, STRINGS) as .comment sections. Like .comment sections,
.GCC.command.line sections are moved to .debug files by debugedit.
New implementation allows to invoke %make_build with a variable
assignments, e.g. LD_LIBRARY_PATH=.libs %make_build check.
A side effect of old %make_build was initialization of NPROCS
environment variable. New %make_build no longer initializes NPROCS,
but, according to specfile scan made by Igor Vlasenko, packages
in Sisyphus do not rely on NPROCS being initialized by %make_build.
Add a brp interface for checking contents of files in buildroot.
The initial revision of brp-check_contents scripts checks
for suspicious path names like /var/lib/run, complementing
the change introduced in sisyphus_check-0.8.43-alt1.
Some of %optflags options, -m* in particular, have to be passed to
assembler so that the output it produces would be consistent with the
output made by compilers.
