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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Some header files have protection against being included into user
code directly. This means that, when processing such files, cpp
is going to fail, and some dependencies probably will be missing.
/usr/include/gtk-2.0/gtk/gtkaccessible.h:
20 #if defined(GTK_DISABLE_SINGLE_INCLUDES) && !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)
21 #error "Only <gtk/gtk.h> can be included directly."
22 #endif
23
24 #ifndef __GTK_ACCESSIBLE_H__
25 #define __GTK_ACCESSIBLE_H__
26
27 #include <atk/atk.h>
28 #include <gtk/gtkwidget.h>
To remedy the problem, we should, as per the above example, process
gtk/gtk.h dependencies recursively. Dependencies which we now attribute
to gtk/gtk.h are: 1) files which are packaged within the same subpackage
- these dependencies will be optimized out later by rpm; 2) the first
file not packaged into this subpackage, which is atk/atk.h. Files below
atk/atk.h are not processed.
Packaged? Stack
+---------------------+
+ | gtk/gtk.h |
+---------------------+
+ | gtk/gtkaccessible.h | <- SPmark
+---------------------+
- | atk/atk.h |
+---------------------+
| ... |
Also note that packaged files in cpp output should not be identified by
filenames, since filenames in the output will be possibly non-canonical.
Therefore I use standard unix technique to identify files by (dev,ino).
/usr/include/boost/spirit/home/support/detail/lexer/containers/ptr_vector.hpp:
9 #include "../size_t.hpp"
This is to improve 'buildreq -bi' support: 'type -t' will stat
absolute paths and buildreq will make self-dependency. Note
that in the next command PATH is nullified to avoid stat/search
for regular commands.
Note that 'sh -e' mode is unreliable when the last pipeline command
is non-simple command (such as while loop). So the script was somehow
failing on hardlinks and it went unnoticed. I choose to replace
pipe-to-while with a temporary file for now.
This finally provides missing strip controls. Note that even with
STRIP_NONE, the file will be edited with debugedit. So there is no
way to bypass brp-debuginfo completely (and maybe we should tolerate
debugedit failures with STRIP_NONE). But there is also an advantage:
/usr/src/debug sources will be installed even for non-stripped files!
This is why sources are now associated with .debuginfo/src/"$f"
instead of .debuginfo/src/"$debugf".
It might seem that build-id links should be created in brp-debuginfo.
However, there are corner cases: in brp-debugino, it is not yet known
which files are going to be packaged. This might be a problem when a
few identical files or hardlinks are created under buildroot: it is
possible create a symbolic link to a "wrong" file which will not be
packaged.
The solution is create build-id links in find-debuginfo-files: the link
will point to the first packaged file with the given build-id. However,
note that find-debuginfo-files is not part of the install stage, and
should remain "reenterable" (so that e.g. rpm -bl can be executed
multiple times). This means that the script should not make assumptions
whether the links have already been created.
- debugedit.c: Imported from rpm.org.
- brp-debuginfo: Initial revision, replaces brp-strip.
- verify-elf: Do not descend into /usr/lib/debug.
- build/checkFiles.c: Skip /usr/lib/debug and /usr/src/debug for now.
- platform.in: Always use -g in %optflags.
