On Tue, 2006-01-03 at 16:41 -0500, Daniel Jacobowitz wrote:
> DESTDIR support (which we already have, and people use constantly)
> allows us to install a tree somewhere different than its configured
> --prefix. Relocatable toolchains (ditto) allow the toolchain to work
> when run from an address d
On Tue, Jan 03, 2006 at 10:39:06PM +0100, Laurent GUERBY wrote:
> On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote:
> > On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> > > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > > > Actually, looking more closely, t
On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > > Actually, looking more closely, the libiberty.a is the only one
> > > > installed
> > > > that way (from
On Tue, 2006-01-03 at 15:54 -0500, Richard Kenner wrote:
> Quick poll: who does configure for some system dir when doing
> development?
>
> I do. Doesn't mean I have to keep doing it that way, of course, but that's
> not what you asked.
I assume linux (and GCC) distributors also do it
On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > Actually, looking more closely, the libiberty.a is the only one installed
> > > that way (from the gcc sources). All others (for example libstdc++.a)
> > > seem
> > > to
Quick poll: who does configure for some system dir when doing
development?
I do. Doesn't mean I have to keep doing it that way, of course, but that's
not what you asked.
On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > Actually, looking more closely, the libiberty.a is the only one installed
> > that way (from the gcc sources). All others (for example libstdc++.a) seem
> > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9).
> > Hmmm...
> Actually, looking more closely, the libiberty.a is the only one installed
> that way (from the gcc sources). All others (for example libstdc++.a) seem
> to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9).
> Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in?
Bingo. :-) http://gcc
Quoting Eric Botcazou <[EMAIL PROTECTED]>:
I've noticed one inconsistency how libraries are installed. For shared
libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
64-bit version is installed in prefix/lib/sparcv9.
For static libraries (lib*.a archives), it is the other
> I've noticed one inconsistency how libraries are installed. For shared
> libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
> 64-bit version is installed in prefix/lib/sparcv9.
>
> For static libraries (lib*.a archives), it is the other way around. The
> 64-bit version is
I've just built gcc with sparc64 as build target (64-bit gcc binary that
generates 64-bit code by default, much like Linux amd64 does).
I've noticed one inconsistency how libraries are installed. For shared
libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
64-bit version i
11 matches
Mail list logo
