[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E4ACFA86-F425-45AA-837F-A43B74524453@palsenberg.com>
Date: Mon, 24 Oct 2011 11:37:40 +0200
From: Igmar Palsenberg <igmar@...senberg.com>
To: owl-dev@...ts.openwall.com
Subject: Re: mpc, gmp, mpfr, gcc .specs
> On Mon, Oct 24, 2011 at 09:05:39AM +0200, Igmar Palsenberg wrote:
>> Is there a reason not to include those libs in-tree in the build ? Building those libs out-of-tree makes the RPM dependent on those version,
>> and makes upgrading them a PITA. Building them in-tree also links them in statically, and that is one library less to be concerned about.
>
> Keeping these libs in their own packages makes the libs available for
> use other than by Owl's gcc - e.g., by a custom build of gcc a user of
> Owl might make (without having to build own prerequisite libs as well)
> and by any other programs (even user's own source code).
There aren't many users for those libs. RHEL uses a different (older) version, so the only user currently is gcc. In my opinion, sensitive libs like this
should be packaged with GCC itself, so the users can switch versions / remove them at will, without breaking gcc.
> In practice, I expect that I will in fact be making custom builds of
> gcc, and saving a few minutes on not having to build the libs each time
> (even if done automatically by gcc's build scripts) is desirable.
It's marginal compared to the gcc build time if you ask me. You want to reconsider, gcc should depend on as few as possible packages.
regards,
Igmar
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.
