[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20111110191121.GD23582@openwall.com>
Date: Thu, 10 Nov 2011 23:11:21 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: missing $(CFLAGS) in several specs
Vasiliy,
On Wed, Nov 09, 2011 at 05:16:32PM +0400, Vasiliy Kulikov wrote:
> 2/3 packages don't always use our %optflags.
The keyword here is "always" - that is, we did previously make sure that
our packages do use %optflags for building their C/C++ source files
(with few exceptions, such as for the kernel). However, approx. 1/3 of
the packages do not use %optflags while linking (which normally does not
matter). I reported this same thing in here a week ago.
> No LDFLAGS or CFLAGS. What's the right pattern for the linkage
> invocation of gcc? Does it need additional $(LDFLAGS) and $(CFLAGS) or
> only $(LDFLAGS)?
I think opinions will vary on this.
I almost thought that we'd need to either have almost all of our
packages (except for special things like the kernel) use %optflags for
both compilation and linking, or we'd need to introduce a separate set
of flags for the linker and have our packages use that. But then I
learned (in part due to the discussion in here, in part on my own) that
other distros simply make -Wl,-z,relro the default in their gcc, and
that they avoid the need to pass -fstack-protector at link time due to
having the required symbols in glibc 2.4+ and/or due to having this
option the default in their patched gcc. As long as these features
would have been the only reasons for us to pass any system-wide options
at link time, we can avoid having to do that in these same ways. So we
do not need to modify our individual packages for this now.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
