[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120423192055.GA9283@openwall.com>
Date: Mon, 23 Apr 2012 23:20:55 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: gcc package updates
Hi Mesut,
On Mon, Apr 23, 2012 at 06:32:24PM +0300, Mesut Can G?rle wrote:
> Finally I can package gcc. The spec file can be accessible from github (
> https://github.com/mesutcang/rpm/blob/master/owl/gcc/gcc.spec). I am still
> working on details. I have a question about gcc. If I don't use
> "--enable-languages=c,c++" configure option packaging fails during
> compilation of java support. Do we need java or fortran etc support for
> gcc? And what is your ideas about bootstrap issue?
So I downloaded
https://raw.github.com/mesutcang/rpm/master/owl/gcc/gcc.spec and diff'ed
it against our gcc.spec in Owl-current. I think the build failure that
you describe above is caused by this change:
-Source0: gcc-core-%version.tar.xz
+Source0: gcc-%version.tar.gz
# ftp://ftp.gnu.org/gnu/gcc/gcc-%version/gcc-core-%version.tar.bz2
# Signature: ftp://ftp.gnu.org/gnu/gcc/gcc-%version/gcc-core-%version.tar.bz2.sig
-%if %BUILD_GXX
-Source2: gcc-g++-%version.tar.xz
-# ftp://ftp.gnu.org/gnu/gcc/gcc-%version/gcc-g++-%version.tar.bz2
-# Signature: ftp://ftp.gnu.org/gnu/gcc/gcc-%version/gcc-g++-%version.tar.bz2.sig
-%endif
In plain English, we were only using the C and C++ tarballs, whereas
you're using a tarball for all GCC-bundled languages. When you do the
latter, you do in fact need to specify --enable-languages=c,c++ to
disable building of other language frontends. I am not surprised that
some of them might require components that are not in Owl.
To answer your other question, no, we don't need to support other
languages in our packaging of gcc. We had such build-time support in
Owl up to and including Owl 3.0, but we saw no demand for it. When it
was broken, no one noticed. So we decided to stop wasting time on it.
The few users who need other languages on Owl will likely do their own
gcc builds (not packaged) or install third-party builds.
BTW, there are a lot of whitespace changes in your gcc.spec - please try
to avoid those.
This gcc update from 4.6.3 to 4.7.0 is expected to be easy. The task
is not so much about updating gcc.spec and regenerating the patch; it is
about doing test buildworlds for i686 and x86_64 with the new gcc.
There _might_ be issues uncovered by that. If so, they will likely need
to be dealt with in other packages (that fail to build with the new gcc).
Thanks,
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.
