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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There's been a few problems.
1) ~/bin should not be checked.
$ /usr/lib/rpm/shell.req -v /dev/stdin <<<vim
warning: no package provides /home/at/bin/vim
shell.req: /dev/stdin: vim not found (skip)
$
Fortunately /usr/bin/which has --skip-tilde option.
2) Check for /etc/alternatives was missing.
$ PATH=/bin:/usr/bin /usr/lib/rpm/shell.req -v /dev/stdin <<<vim
shell.req: /dev/stdin: vim -> /usr/bin/vim -> vim-X11
vim-console
vim-enhanced (via rpmdb)
vim-X11
vim-console
vim-enhanced
$
This is why FindByName should ultimately call FindByPath.
After this change, it works just fine:
$ scripts/shell.req.in -v /dev/stdin <<<vim
shell.req.in: /dev/stdin: vim -> /usr/bin/vim -> ... (via which)
shell.req.in: /dev/stdin: /usr/bin/vim -> /usr/bin/vim (alternative)
/usr/bin/vim
$
Also enabled /usr/bin/which --all option and added diagnostics
for really ambiguous cases.
Actually if you think about it a few hours or so... you may come to
know that FindByName() should ultimately call FindByPath(). But this
will be the next commit.
Moved old code from find-requires and find-provides to lib.req and lib.prov.
For some reason, also a few python-related lines was removed.
Adapted lib.req and lib.prov to work without RPM_BUILD_ROOT.
In lib.prov, simplified RPM_FINDPROV_LIB_PATH handling (replaced
`lookup_path "$dir" "$PATH"' with `[ -z "${PATH##* $dir *}" ]').
Added lib.req.files and lib.prov.files.
Perl extensions are now automatically linked with libperl (starting with
rpm-build-perl >= 0.6.0-alt1, and natively starting with perl-devel >= 1:5.8.8-alt5).
Also enhanced the scripts by using pkg-config --print-errors, because
pkg-config is silent by default. Also added checks for pkg-config exit
status and valid output.
Also changed the order: libdir/pkgconfig:datadir/pkgconfig instead of
datadir/pkgconfig:libdir/pkgconfig, according to pkg-config(1).
See my previous commit. It goes like this:
$ /usr/lib/rpm/shell.req -v /usr/bin/buildreq
shell.req: /usr/bin/buildreq: cat -> /bin/cat -> coreutils (via rpmdb)
shell.req: /usr/bin/buildreq: cmp -> /usr/bin/cmp -> diffutils (via rpmdb)
shell.req: /usr/bin/buildreq: function(Info) not found (skip)
shell.req: /usr/bin/buildreq: function(show_help) not found (skip)
shell.req: /usr/bin/buildreq: function(show_usage) not found (skip)
shell.req: /usr/bin/buildreq: rm -> /bin/rm -> coreutils (via rpmdb)
shell.req: /usr/bin/buildreq: sed -> /bin/sed -> sed (via rpmdb)
coreutils
diffutils
sed
$
I argue that this behaviour, i.e. function(Info) processing, is erroneous.
There are two reasons: 1) it is impossible to resolve function(Info) neither
via FindPackage nor via .provides.sh (the latter has just plain function names);
2) the fact that Info has been detected as function means that Info() function
is defined in the very same file, i.e. /usr/bin/buildreq. This means that
function(Info) is self-provided dependency and thus should not be processed
at all.
Now it works like this:
$ /usr/lib/rpm/shell.req -v /usr/bin/buildreq
shell.req: /usr/bin/buildreq: cat -> /bin/cat -> coreutils (via rpmdb)
shell.req: /usr/bin/buildreq: cmp -> /usr/bin/cmp -> diffutils (via rpmdb)
shell.req: /usr/bin/buildreq: function(Info) not found (skip)
shell.req: /usr/bin/buildreq: function(show_help) not found (skip)
shell.req: /usr/bin/buildreq: function(show_usage) not found (skip)
shell.req: /usr/bin/buildreq: rm -> /bin/rm -> coreutils (via rpmdb)
shell.req: /usr/bin/buildreq: sed -> /bin/sed -> sed (via rpmdb)
coreutils
diffutils
sed
$
It looks like there's a problem with function(Info) here.
Verbosity is a good thing.
This is the dependency generator for #! lines.
shebang.req.files makes sure that only executable scripts are processed.
Here is why I chose the "shebang" name.
From Jargon File (4.3.1, 29 Jun 2001) [jargon]:
shebang /sh*-bang/ n. The character sequence "#!" that frequently
begins executable shell scripts under Unix. Probably derived from "shell
bang" under the influence of American slang "the whole shebang"
(everything, the works).
$ cd /usr/lib/perl5/pod
$ grep -i sharpbang *
perltoc.pod:C<shar>, C<sharpbang>, C<shmattype>, C<shortsize>, C<shrpenv>, C<shsharp>,
$ grep -i shebang *
perl58delta.pod:The command-line options -s and -F are now recognized on the shebang
perlbs2000.pod:BS2000 POSIX doesn't support the shebang notation
perlfaq3.pod:batch file and codify it in C<ALTERNATE_SHEBANG> (see the
perlfaq7.pod:line in your perl script (the "shebang" line) does not contain the
perlfaq7.pod:where you expect it so you need to adjust your shebang line.
perlfaq8.pod:but my shebang line is not the path to perl, so the shell runs the
perlglossary.pod:=item shebang
perljp.pod: "shebang"ѹǡJperlѤscriptΤۤȤɤѹʤѲǽȻפޤ
perlplan9.pod:such as "#!/usr/local/bin/perl". This is known as a shebang
perlplan9.pod:shebang path from config information located in Plan 9
perlport.pod:sub-systems do not support the C<#!> shebang trick for script invocation.
perlport.pod:OS/390 will support the C<#!> shebang trick in release 2.8 and beyond.
perlrun.pod:C<ALTERNATE_SHEBANG> (see the F<dosish.h> file in the source
perltoc.pod:serialization, server, service, setgid, setuid, shared memory, shebang,
perlwin32.pod:Perl scripts on UNIX use the "#!" (a.k.a "shebang") line to
$
1) added scripts/shell.req.files and scripts/shell.prov.files.
scripts/shell.req.files has new patterns for '/usr/bin/env bash'
and '/bin/ash'.
2) adapted scripts/shell.req.in and scripts/shell.prov.in
by using ArgvFileAction. Also made them work with empty RPM_BUILD_ROOT.
Note: now shell.req produces dependencies from .provides.sh even
if the latter is inside RPM_BUILD_ROOT. The reason is that .provides.sh
and the script can reside in two different subpackages (and otherwise,
rpm will optimize out the dependency).
3) removed corresponding old code from autodeps/linux.req.in
and autodeps/linux.prov.in.
This function provides "standard calling conventions" for req/prov methods.
The idea is that the shell script which implements a req/prov method need
not know how exactly it was called and how it should process its arguments.
Instead, it should impelment a function which takes exactly one argument,
which is filename, say MyReq, and finally just call
ArgvFileAction MyReq "$@"
Standard input to argv conversion is then done automatically and transparently.
This will also enable scripts to process real argv arguments, if any,
instead of standard input (but fall back to standard input otherwise).
I also added --help and -v|--verbose options. Surprisingly enough,
the latter increases RPM_SCRIPTS_DEBUG level.
Also added non-intrusive canonicalization of pathnames, hence the name
ArgvFileAction. This is not going to affect rpm-build, but hopefully
this can help when the script is invoked manually.
find-requires is now a dispatcher for /usr/lib/rpm/*.req scripts (methods).
find-provides is now a dispatcher for /usr/lib/rpm/*.prov scripts (methods).
The algorithm is basically as follows:
1) Filter input file list through TOPDIR and SKIPLIST patterns.
2) Run the resulting file list through file(1), which output is (per line)
<input-file-name><tab><optional-single-space><file-magic-type>
3) For each req/prov methods, there must be corresponding *.files
filter (e.g. /usr/lib/rpm/perl.req.files for /usr/lib/rpm/perl.req).
We feed file(1) output to this filter; the filter must print the list
of <input-files-name>s (per line) which will be processed with the
corresponding req/prov method.
4) Each req/prov method is invoked with corresponding file list on its
standard input. The method must output valid rpm dependencies (per line)
or exit with non-zero code.
Notes:
Unlike find-requires, find-provides runs file(1) with -L option.
RPM_FINDREQ_DEFAULT_METHOD and RPM_FINDPROV_DEFAULT go away.
All available methods are run by default.
The old code has been kept. I am going to remove it gradually
as I factor particular req/prov scripts.
I want some rpm scripts to be modular, so that e.g. adding new automatic
dependencies does not require ad hoc modifications.
The plan is as follows: I am going to manage methods. Methods
are scripts which e.g. implement particular dependency detection.
The set of methods is defined by its suffix, so that /usr/lib/rpm/*.req
are all "req" methods (the "req" method set).
Hereby I provide two functions which abstract the usage of method sets.
1)
methods=$(SetupMethods SETID WANTED_METHODS)
Returns (prints) the list of active methods identified by SETID.
The SETID argument, according to the above, should be filename suffix.
Performs a check if all WANTED_METHODS are available. WANTED_METHODS is
a space and/or comma separated list of method basenames, e.g. "perl" for
/usr/lib/rpm/perl.req. The list of WANTED_METHODS is also interpreted
according to AutoReqProv tag rules, i.e. "yes" to enable all methods,
"no" to disable all methods, "noperl" to exclude "perl" etc.
When no methods are active, the output string is guaranteed to be empty.
2)
RunMethods SETID "$methods" [CMD...]
Executes method set scripts identified by SETID; the list of methods
"$methods" must be obtained from SetupMethods. CMD can warp method script
execution.
I am going to make certain req/prov scripts work even with empty
RPM_BUILD_ROOT (so that I can analyze the dependencies within the
host system). This probably means that I will remove ValidateBuildRoot
clause from the script. However, since non-empty RPM_BUILD_ROOT still
must be valid, I place the check here.
Just setting -x is very noisy. Here is a better plan. I implement 3
debug levels: verbose (1), debug (2, implies verbose) and -x (3, implies
debug). I move RPM_SCRIPTS_DEBUG test from scripts to scripts/functions,
as well as provide Verbose() and Debug() shell functions for use in scripts.
Furthermore, _scripts_debug macro is now automatically set when rpmbuild
is invoked with --verbose option. Use -vv for debug and -vvv for -x.
This is probably the last gendiff-related commit for now.
I think I want to propose the following changelog entry
for next rpm release:
- enhanced gendiff(1), which can now recognize whitespace-related
subset of GNU diff options (Alexey Tourbin)
TODO: make it recognize more diff options.
But option values must be quoted...
-mtune=i686 does not differ from -mtune=generic for gcc-4.1.x
(see gcc/config/i386/i386.c for details),
but -mtune=generic is not implemented in older gcc.
- platform.in: Changed %%optflags_kernel to %%nil.
- rpmrc.in: Changed %%optflags_default to use -mtune=generic
instead of -mtune=pentium4 for i[3456]86 (Alexey Tourbin).
We use i586 as our default generic arch for x86 processors.
But -mtune=pentium4 is preferable only for Intel processors,
and possibly disadvantageous for AMD chips.
I suggest we use -mtune=generic instead. Here is what "man gcc" says
about -mtune=generic:
Produce code optimized for the most common IA32/AMD64/EM64T
processors. If you know the CPU on which your code will run, then
you should use the corresponding -mtune option instead of
-mtune=generic. But, if you do not know exactly what CPU users of
your application will have, then you should use this option.
As new processors are deployed in the marketplace, the behavior of
this option will change. Therefore, if you upgrade to a newer
version of GCC, the code generated option will change to reflect the
processors that were most common when that version of GCC was
released.
Now if you're willing to take a look at gcc/gcc/config/i386/i386.c,
you can see that -mtune= option affects only "instruction costs".
For example, AMD chips take fewer cycles to execute some divide/mod
instructions than Intel processors. Instruction costs can affect
peephole optimizer or something to make the resulting instruction
sequence take fewer cycles. It appears that "generic32_cost" provides
reasonable compromise so that the resulting code runs quite well
on all modern CPUs.
Update. I've been requested to provide some numbers.
I use perlbench-0.93 suite to measure libperl.so performance.
A) libperl.so compiled with -march=i586 -mtune=pentium4
B) libperl.so compiled with -march=i586 -mtune=generic
AMD Athlon 64 A B
------------- --- ---
arith/mixed 100 106
arith/trig 100 100
array/copy 100 104
array/foreach 100 94
array/index 100 108
array/pop 100 109
array/shift 100 107
array/sort-num 100 103
array/sort 100 100
call/0arg 100 105
call/1arg 100 96
call/2arg 100 101
call/9arg 100 107
call/empty 100 108
call/fib 100 103
call/method 100 106
call/wantarray 100 107
hash/copy 100 99
hash/each 100 91
hash/foreach-sort 100 96
hash/foreach 100 100
hash/get 100 102
hash/set 100 110
loop/for-c 100 104
loop/for-range-const 100 102
loop/for-range 100 103
loop/getline 100 106
loop/while-my 100 109
loop/while 100 113
re/const 100 104
re/w 100 102
startup/fewmod 100 104
startup/lotsofsub 100 107
startup/noprog 100 100
string/base64 100 102
string/htmlparser 100 102
string/index-const 100 110
string/index-var 100 74
string/ipol 100 105
string/tr 100 102
AVERAGE 100 103
Intel Xeon A B
---------- --- ---
arith/mixed 100 98
arith/trig 100 138
array/copy 100 101
array/foreach 100 100
array/index 100 94
array/pop 100 99
array/shift 100 117
array/sort-num 100 103
array/sort 100 105
call/0arg 100 101
call/1arg 100 97
call/2arg 100 93
call/9arg 100 98
call/empty 100 100
call/fib 100 116
call/method 100 92
call/wantarray 100 101
hash/copy 100 104
hash/each 100 102
hash/foreach-sort 100 102
hash/foreach 100 98
hash/get 100 102
hash/set 100 96
loop/for-c 100 128
loop/for-range-const 100 100
loop/for-range 100 103
loop/getline 100 94
loop/while-my 100 107
loop/while 100 102
re/const 100 99
re/w 100 92
startup/fewmod 100 101
startup/lotsofsub 100 98
startup/noprog 100 101
string/base64 100 100
string/htmlparser 100 70
string/index-const 100 103
string/index-var 100 101
string/ipol 100 105
string/tr 100 94
AVERAGE 100 101
Look ma, I've got about 3% performance boost on Athlon64 and even some
minor improvement on Intel Xeon! Also notice that, on Xeon, the
numbers are more diverse. I believe that the numbers prove that,
compared to -mtune=pentium4, -mtune=generic is beneficial for Athlon64
and at least makes no harm for Xeon.
Here is how to run perlbench:
$ echo ${PWD##*/}
perlbench-0.93
$ cat perl1 perl2
LD_LIBRARY_PATH=$PWD/lib1 exec /usr/bin/perl "$@"
LD_LIBRARY_PATH=$PWD/lib2 exec /usr/bin/perl "$@"
$ ls -l lib?/libperl*
-rw-r--r-- 1 at at 1173944 Jan 9 03:42 lib1/libperl.so.5.8
-rw-r--r-- 1 at at 1204984 Jan 9 03:46 lib2/libperl.so.5.8
$ ./perlbench-run ./perl1 ./perl2
...
