On 04/22/2009 12:56 PM, Orcan Ogetbil wrote:
> As you probably know that some packages add their own compiler flags
> on top of what we specified as %optflags. Until now, I did not do
> anything about these flags unless they override our %optflags. Now,
> having a second thought, I realized that the above statement can be
> interpreted in two ways:
>
> 1- The extra flags are added by the packager: This is the way I used
> to interpret the guideline, and I always document if I add additional
> flags on top of %{optflags}
If the packager is adding optflags above and beyond what is in
%{optflags} as a manual action (not something inherited by upstream),
they need to have a darned good reason to do so, and that reason should
be documented in a comment next to this action in the spec file.
> 2- The extra flags are added by the build script of upstream: Here is
> the question: Do we need to document such cases in the specfile? I
> know that we have hundreds (maybe thousands) of packages which don't
> document this case in the specfile. Are such packages violating the
> above guideline?
In a perfect world, yes, this should be documented in the spec file, but
practically, you're right, the upstreams often set specific compiler
flags for valid reasons, but don't bother explaining them at all. In
general, when the upstream compiler flags do not conflict with our
%{optflags} and do generally sane things, I think it is okay to permit
them. I know that is vague, but its the best answer I can give. In
general, I trust that upstreams are not being idiots. If it is obvious
that this is not true, the packager may want to reconsider their choice
of additional compiler flags.
> Second question: From the same link above:
> "Compilers used to build packages should honor the applicable compiler
> flags set in the system rpm configuration."
>
> Does this apply to the stage where the compiler is doing the linking,
> i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in
> this stage too? Again, I know many packages that don't pass %optflags
> to the compiler during the linking. Do these pakcages violate the
> guideline?
Generally, the answer here is no, as most of the time, these flags are
just converted to ld flags, and the only one that really ever matters
seems to be the -m32/-m64 split to ensure that resultant binary is
linked at the proper bitsize. I've only ever seen this break on sparc64,
and it is no longer an issue, since the ld defaults are now sane on that
arch.
~spot
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
