[EMAIL PROTECTED] wrote:
On Fri, 25 May 2007, Tim Prince wrote:
I spent quite a while getting out of the tangle I got into when I built
mpfr and gmp with --disable-shared, leaving older incompatible shared
libraries in the path. No doubt, it can be made to work, but with
plenty of ways to go w
On Fri, 25 May 2007, Tim Prince wrote:
> I spent quite a while getting out of the tangle I got into when I built
> mpfr and gmp with --disable-shared, leaving older incompatible shared
> libraries in the path. No doubt, it can be made to work, but with
> plenty of ways to go wrong.
The above isn
[EMAIL PROTECTED] wrote:
However there are two existing options in the mean time:
One is build/install gmp/mpfr yourself and specify --disable-shared to
both. Then use --with-mpfr= to specify using them instead of the system's
shared versions.
The second is to drop gmp/mpfr into the top leve
> That just means that it's an application you care about. And now an
> upgrade of MPFR which fixes bugs will require you to rebuild the
> compiler.
Exactly. By design. What goes in the system compiler should be closely
scrutinized.
--
Eric Botcazou
On Fri, 25 May 2007, Dave Korn wrote:
> On 25 May 2007 15:34, Eric Botcazou wrote:
>
> Yes, hasn't this been one of the design goals of gcc for as long as any of
> us can remember? It wants to be able to bootstrap the GNU world on non-free
> systems from scratch and part of that is not requirin
On Fri, 25 May 2007, Daniel Jacobowitz wrote:
> On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
> > > I honestly don't know how to answer this question. Bootstrapping is an
> > > unrelated problem, and the compiler is not a vital runtime component
> > > of the system, so its depend
> Bootstrapping GCC on a system is something that would be solved by
> placing GMP and MPFR in the build tree (as has been proposed), and once
> they are built as part of the usual bootstrap, it is irrelevant whether
> they are linked statically or dynamically. On the other hand, when one
> is dis
> I honestly don't know how to answer this question. Bootstrapping is an
> unrelated problem, and the compiler is not a vital runtime component
> of the system, so its dependencies do not need to be exceptionally
> robust in the way that glibc's or even libstdc++'s do.
A compiler is a "second ord
On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
> > I honestly don't know how to answer this question. Bootstrapping is an
> > unrelated problem, and the compiler is not a vital runtime component
> > of the system, so its dependencies do not need to be exceptionally
> > robust in th
On 25 May 2007 07:52:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Tim Prince <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > If you
> > carefully install the appropriate versions of GMP and MPFR on one
> > machine in the normal way, and build gcc on that machine,
> > cc1/cc1p
Dave Korn wrote:
On 25 May 2007 15:34, Eric Botcazou wrote:
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave
Tim Prince <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > If you
> > carefully install the appropriate versions of GMP and MPFR on one
> > machine in the normal way, and build gcc on that machine,
> > cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
> > libmpfr.so. If
On 25 May 2007 15:34, Eric Botcazou wrote:
>> It's no different than any other library used by any other program.
>> I wouldn't object to configure support to request static gmp/mpfr for
>> developer convenience, but GCC is a perfectly normal dynamically
>> linked program and should behave like on
On Fri, May 25, 2007 at 04:33:56PM +0200, Eric Botcazou wrote:
> > It's no different than any other library used by any other program.
> > I wouldn't object to configure support to request static gmp/mpfr for
> > developer convenience, but GCC is a perfectly normal dynamically
> > linked program an
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
> I just noticed a problem with our use of GMP and MPFR. If you
> carefully install the appropriate versions of GMP and MPFR on one
> machine in the normal way, and build gcc on that machine,
> cc1/cc1plus/etc. wind up dynamically l
> It's no different than any other library used by any other program.
> I wouldn't object to configure support to request static gmp/mpfr for
> developer convenience, but GCC is a perfectly normal dynamically
> linked program and should behave like one IMO.
How a compiler can be "a perfectly norma
On 5/25/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
> We need a configure time option to link statically against GMP and
> MPFR even if dynamic versions of the libraries are available.
>
> I would argue that static linking sho
[EMAIL PROTECTED] wrote:
If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to some other system, or
simply
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
> We need a configure time option to link statically against GMP and
> MPFR even if dynamic versions of the libraries are available.
>
> I would argue that static linking should be the default, since that is
> the least surprising o
On 25 May 2007 15:10, Ian Lance Taylor wrote:
> I would argue that static linking should be the default, since that is
> the least surprising option. People who understand the issues can
> enable dynamic linking.
And besides, wasn't it the case that one of the main points in defence of
addi
I just noticed a problem with our use of GMP and MPFR. If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to
21 matches
Mail list logo
