On Sat, 2014-09-13 at 05:44 +0200, Ralf Corsepius wrote:
> On 09/12/2014 10:53 PM, Mark Wielaard wrote:
> > Maybe people misunderstand that to mean they have to include the whole
> > file in their local source copy instead of just simply #include it?
>
> Possibly. I am not sufficiently familiar with valgrind to be able to
> judge. It would depend upon what "valgrind.h" actually does.
> If it causes packages to be statically linked against valgrind libs, it
> would at least be legally "muddy terrain", to say the least.
You could see what valgrind.h inserts as "markers" in the code. They
don't actually "activate" or call any code. They just tell valgrind
"here is a pointer to a block of memory that has the following
properties". They are just expressed as "code" that does nothing. That
is because that is the most convenient for valgrind. valgrind
interprets/transforms/compiles machine code. The "machine code snippets"
are supposed to do nothing (modulo bugs, like in the ppc32 case) when
run on a real processor. In theory other runtime code sanitizers could
take advantage of these markers (but in practice I don't know of any
that do).
> >> What these packages are doing is similar to bundling and static linkage,
> >> and suffers from similar consequences, such the issues you currently are
> >> having.
> >
> > Yes, indeed. Should they add something like
> > Provides: bundled(valgrind.h)
> Do they only bundle valgrind.h or more of valgrind?
Normally only valgrind.h and sometimes the valgrind tool specific files
(memcheck.h, callgrind.h, etc.) that define additional markers for
specific valgrind tools.
> > I am not sure what the correct policy is in the case of a single (or a
> > handful of) header files included as private copies.
> OK, you seem to be saying "header only".
>
> Such cases are not uncommon to find in "C++" packages ("Header-only
> libs"), but are fairly rare for "C" (C lacks C++-"templates").
> We (FPC) commonly treat them as a special case of both bundling and
> copylibs.
>
> If this use-case is technically useful, it probably would be useful to a
> "Provides: bundled(valgrind.h) = <version>" to these packages, to make
> them easier identifiable in future.
>
> Should this use-case not be technically useful (E.g to shadowing
> valgrind's API/ABI), then enforcing using the external package should be
> mandatory.
I think you can see them like c++ header only "libs" (but they probably
"do less" than a c++-template header file).
I am not sure how to define "technically useful". I am sure it was
useful for these packages so they didn't have to depend on or embed all
of valgrind. The files are small and self contained on purpose. Looking
at some of them, it has been done since before 3.5.0 when valgrind.h
started including the valgrind version number in that file, which was
more than 5 years ago. But currently they are giving me a little
headache :) The ppc32 bug is not that important in the fedora case since
f21 dropped ppc32 support. But these packages are missing valgrind
support for ppc64le and aarch64, which is a pity.
> > I was just going to
> > file bug reports against the packages to request they either update the
> > private copy (or ask upstream to) or remove them and add
> > BuildRequires: valgrind-devel and just #include the system copy.
> Sounds reasonable to me.
>
> It also would seem reasonable to me to file a ticket to FPC, such that
> FPC can try to examine this case.
I have to apologize for not knowing how to file a ticket to FPC. Where
would I do that? I did file a tracking bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1141461
Specific packages that I identified to contain a private copy of
valgrind.h have a bug filed that blocks that tracker bug.
Thanks,
Mark
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
