Re: Hardened builds

2015-03-07 Thread Moez Roy
On Fri, Mar 6, 2015 at 2:01 PM, Jerry James loganje...@gmail.com wrote:

 Oops, sorry, got distracted.  It is polymake.  That package has
 multiple problems.

 First, it invokes undefined behavior in one bit of code.  That
 happened to work out with gcc 4.x, but gcc 5.x compiles the code a bit
 differently, resulting in a scrambled data structure that causes a
 crash sometime later.  Tracing that down was sure a pain, but I
 finally found it, and will definitely tell upstream to fix their code.


Can you post a link here for that gcc regression bug? Thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-03-07 Thread Jerry James
On Sat, Mar 7, 2015 at 12:52 PM, Moez Roy moez@gmail.com wrote:
 Can you post a link here for that gcc regression bug? Thanks.

There is no regression.  The source code invoked undefined behavior.
Under such circumstances, the compiler is free to do anything at all.
Things just happened to work out right with gcc 4.x, but the fact that
it doesn't work out right with gcc 5.x is not gcc's fault.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-03-06 Thread Michael Cronenworth

On 02/24/2015 06:44 PM, Jerry James wrote:

How is this really supposed to be done?  If I'm doing it the right
way, then the current method is broken.



%undefine _hardened_build

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-03-06 Thread Jerry James
On Thu, Feb 26, 2015 at 11:00 AM, Rex Dieter rdie...@math.unl.edu wrote:
 which package is this again?  I can try experimenting a bit.

 The one that worked for me was lightdm, fwiw.

Oops, sorry, got distracted.  It is polymake.  That package has
multiple problems.

First, it invokes undefined behavior in one bit of code.  That
happened to work out with gcc 4.x, but gcc 5.x compiles the code a bit
differently, resulting in a scrambled data structure that causes a
crash sometime later.  Tracing that down was sure a pain, but I
finally found it, and will definitely tell upstream to fix their code.

Second, polymake queries perl::Config for the flags perl was built
with, and perl was built with the hardening flags.  No wonder I
couldn't get rid of them.

Third, polymake has a number of plugins (apps in polymake parlance),
some of which depend on each other, but they are not linked to one
another.  The main application knows about the dependencies between
them and dlopens them in the correct order to avoid unresolved
symbols.  However, it also has a documentation building step, which
dlopens them one by one to extract documentation strings.  This is
fine, because no code in the plugins is actually executed.  At least,
it used to be fine back when RTLD_LAZY actually worked.  Now it causes
the documentation building step to fail due to unresolved symbols.
The question is whether I can fix this by altering polymake alone, or
whether a non-hardened perl is needed to make this work.  I'm still
experimenting to discover the answer to that question.  (Polymake
builds take awhile and gobble memory like it was doughnuts, so this
isn't a fast process.)
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-02-28 Thread Christopher Meng
On Saturday, February 28, 2015, Till Maas opensou...@till.name wrote:

 I am going to get this updated once the mass rebuild is done and I got
 the details worked out about what to do best, for example for allowing
 exceptions from this.


You gonna allow many exceptions as some packages on x86_64 failed to build.


-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-02-27 Thread Till Maas
On Tue, Feb 24, 2015 at 05:44:18PM -0700, Jerry James wrote:

 Also, http://fedoraproject.org/wiki/Hardened_Packages seems to be
 entirely useless at this point.  Perhaps it could be replaced with a
 page that discusses the current state of the hardening flags.

I am going to get this updated once the mass rebuild is done and I got
the details worked out about what to do best, for example for allowing
exceptions from this.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-02-26 Thread Rex Dieter
Jerry James wrote:

 On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter rdie...@math.unl.edu wrote:
 Mamoru TASAKA wrote:
 Does
 %undefine _hardened_build
 help?

 that version works for me
 
 Hmmm, am I doing something wrong?  I've tried both:
 
 %undefine _hardened_build
 
 and:
 
 %undefine _hardened_build
 %global _hardened_build 0
 
 at the top of the spec file, and in both cases, I still see the
 hardened specs in CFLAGS and LDFLAGS when %configure is invoked.  I've
 got the right spec file inside the mock root.  I don't understand
 why this worked for you and isn't working for me.

which package is this again?  I can try experimenting a bit.

The one that worked for me was lightdm, fwiw.

-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

RE: Hardened builds

2015-02-25 Thread Rex Dieter
Mamoru TASAKA wrote:

 Hello:
 
 I've got a package that is currently failing to build in Rawhide.  It
 has a home-brewed garbage collector inside, and it appears the GC is
 confused about which objects are on the stack, and which are on the
 heap.  I want to try building without the hardening flags to see if
 that has something to do with the problem.  According to
 https://fedorahosted.org/fesco/ticket/1384 the way to do this is to
 put:
 
 %global _hardened_build 0
 
 at the top of the spec file.  But that doesn't work with a local mock
 build.  I still see -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 in
 the compiler flags and -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
 in the linker flags.
 
 Does
 %undefine _hardened_build
 help?

that version works for me

-- Rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-02-25 Thread Jerry James
On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter rdie...@math.unl.edu wrote:
 Mamoru TASAKA wrote:
 Does
 %undefine _hardened_build
 help?

 that version works for me

Hmmm, am I doing something wrong?  I've tried both:

%undefine _hardened_build

and:

%undefine _hardened_build
%global _hardened_build 0

at the top of the spec file, and in both cases, I still see the
hardened specs in CFLAGS and LDFLAGS when %configure is invoked.  I've
got the right spec file inside the mock root.  I don't understand
why this worked for you and isn't working for me.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

RE: Hardened builds

2015-02-24 Thread Mamoru TASAKA
Hello:

 I've got a package that is currently failing to build in Rawhide.  It
 has a home-brewed garbage collector inside, and it appears the GC is
 confused about which objects are on the stack, and which are on the
 heap.  I want to try building without the hardening flags to see if
 that has something to do with the problem.  According to
 https://fedorahosted.org/fesco/ticket/1384 the way to do this is to
 put:
 
 %global _hardened_build 0
 
 at the top of the spec file.  But that doesn't work with a local mock
 build.  I still see -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 in
 the compiler flags and -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
 in the linker flags.  

Does
%undefine _hardened_build
help?

Regards,
Mamoru


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Hardened builds

2015-02-24 Thread Jerry James
On Tue, Feb 24, 2015 at 6:26 PM, Mamoru TASAKA
mtas...@fedoraproject.org wrote:
 Does
 %undefine _hardened_build
 help?

Thanks for the suggestion, but regrettably, now %configure does this:

checking C++ compiler ... ok (g++ is GCC 5.0)
determining architecture ... ok (x86_64)
determining compiler flags ... ok
   CFLAGS=%{optflags} -I%{_includedir}/eigen3 -Wno-unused-local-typedefs -Wall
   CXXFLAGS=%{optflags} -I%{_includedir}/eigen3
-Wno-unused-local-typedefs -ftemplate-depth-200 -Wall
-Wno-strict-aliasing -Wno-parentheses -fwrapv -fopenmp
checking gmp installation ... Could not compile a test program
checking for the GNU Multiprecision Library (GMP).
The complete error log follows:
g++: error: %{optflags}: No such file or directory

I'm going to sleep on it and see what I can come up with tomorrow.

The mock explosion, by the way, appears to be unrelated.  I think what
happened is that I did one mock run with -r fedora-rawhide-x86_64,
then wanted to do another without blowing away the first, so I added a
--uniqueext argument.  Then later, I did a mock --clean
--uniqueext=, and after that the next mock --rebuild ...
--uniqueext=... threw that error.  I will try to reproduce later and
file a bug report.

Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct