On 08/22/2011 07:11 PM, Rainer Orth wrote:
installed, thanks.
Do I need to sync the config and libiberty parts to src manually or does
this happen by some sort of magic?
I'll take care of that.
Paolo
On 08/19/2011 09:11 PM, Rainer Orth wrote:
2011-07-31 Rainer Orthr...@cebitec.uni-bielefeld.de
config:
* picflag.m4: New file.
gcc:
* configure.ac (GCC_PICFLAG_FOR_TARGET): Call it.
(PICFLAG_FOR_TARGET): Substitute.
* aclocal.m4: Regenerate.
Paolo Bonzini bonz...@gnu.org writes:
On 08/19/2011 09:11 PM, Rainer Orth wrote:
2011-07-31 Rainer Orthr...@cebitec.uni-bielefeld.de
config:
* picflag.m4: New file.
gcc:
* configure.ac (GCC_PICFLAG_FOR_TARGET): Call it.
(PICFLAG_FOR_TARGET): Substitute.
*
Do I need to sync the config and libiberty parts to src manually or does
this happen by some sort of magic?
intl/; config.rhost; libiberty/; libiberty's part of include/
gcc: http://gcc.gnu.org
Changes need to be done in tandem with the official GCC
sources or
DJ Delorie d...@redhat.com writes:
Do I need to sync the config and libiberty parts to src manually or does
this happen by some sort of magic?
intl/; config.rhost; libiberty/; libiberty's part of include/
gcc: http://gcc.gnu.org
Changes need to be done in tandem with the
Paolo,
I've actually changed it to honor both -fpic and -fPIC in CFLAGS
(resp. CFLAGS_FOR_TARGET).
I'll fire off i386-pc-solaris2.10 and x86_64-unknown-linux-gnu
bootstraps before leaving for home tonight, but the following patch has
already been tested lightly with a minimal configure
Mike Stump mikest...@comcast.net writes:
On Aug 15, 2011, at 10:53 AM, Rainer Orth wrote:
* git libtool.m4 uses -fno-common on *-*-darwin. No idea if this is
required.
Yes, it is.
Fine, thanks. I was just confused by the fact that it isn't currently
used to build the shared libgcc.
Paolo,
On 08/16/2011 09:53 AM, Rainer Orth wrote:
actually makes some sense---so the general approach in your patch is
good.
Indeed, but IMO it makes sense in general, not only for SPARC, but for
all targets that distinguish between -fpic and -fPIC.
The patch is okay.
You mean as
On Aug 18, 2011, at 10:03 AM, Rainer Orth wrote:
Mike Stump mikest...@comcast.net writes:
On Aug 15, 2011, at 10:53 AM, Rainer Orth wrote:
* git libtool.m4 uses -fno-common on *-*-darwin. No idea if this is
required.
Yes, it is.
Fine, thanks. I was just confused by the fact that it
Wouldn't you use these targets with --disable-target-libada
--disable-gnattools?
Yes (or rather --disable-libada. I believe also disable-libada implies
--disable-gnattols), that's the primary use (manual debugging
is a secondary use).
Arno
That's the simplest alternative. It would need however a pass through the
config/ directory for targets that are never used as hosts for GCC (and
thus libiberty).
Alternatively, the libtool code could be extracted to config/picflag.m4.
Alternatively, one could think about using
Arnaud Charlet char...@adacore.com writes:
Yes, that needs to be done of course. I'm not sure if we still support
gnatlib_and_tools to build libada/gnattools. If so, we would need the
PICFLAG to be available somehow in the gcc Makefile (perhaps by providing
GCC_TARGET_PICFLAG in addition to
Steve,
On Mon, 2011-08-15 at 19:53 +0200, Rainer Orth wrote:
* For IA64 HP-UX, there's a claim that -fPIC is necessary despite PIC
code being the default. I could find no hint in trunk that this is
true any longer.
Rainer, If I recall correctly the issue for -fPIC on IA64 HP-UX is to
Ok, I see. Perhaps gcc/ada could be disentangled and those files
exclusively or primarily used for libgnat/libgnarl moved over to libada,
and referenced from there for the host build?
That would require some delicate work on AdaCore's side, so wouldn't be
helpful in the short term (rather
Paolo Bonzini bonz...@gnu.org writes:
On 08/15/2011 10:53 AM, Rainer Orth wrote:
* The general approach between libtool and libiberty differs. Unless
otherwise specified (PIC is the default or doesn't work for some
reason), libtool defaults to -fPIC, while libiberty has a strange
Arnaud Charlet char...@adacore.com writes:
Ok, I see. Perhaps gcc/ada could be disentangled and those files
exclusively or primarily used for libgnat/libgnarl moved over to libada,
and referenced from there for the host build?
That would require some delicate work on AdaCore's side, so
On 08/16/2011 09:52 AM, Arnaud Charlet wrote:
I've often had serious trouble when I tried to run make
gnatlib/gnatlib-shared in gcc/ada.
Apparently someone in the past removed too many things from the Makefile
which broke partly this support (probably thinking that with libada/Makefile,
On 08/16/2011 09:44 AM, Rainer Orth wrote:
So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not
just via libada/Makefile is indeed important.
This seems to be easy: unless I'm mistaken, it should suffice to just
call GCC_PICFLAG in gcc/configure.ac and substitute the result
On 08/16/2011 09:53 AM, Rainer Orth wrote:
actually makes some sense---so the general approach in your patch is good.
Indeed, but IMO it makes sense in general, not only for SPARC, but for
all targets that distinguish between -fpic and -fPIC.
The patch is okay.
You mean as is, with all
Sure, I was rather asking how make gnatlib (or whatever) is supposed to
be invoked? From gcc/ada, any special needs?
From obj dir/gcc typically.
It would be good to contribute them, perhaps for close scrutiny by a
well, it's not a matter of contributing: it's more a matter of undoing what
Please post them.
OK, here they are. FWIW, I have no idea how these changes will play with
libada (in particular the stamp-tools handling), so I suspect these changes
may require a bit of adjustment to be suitable.
Arno
--- gcc-interface/Make-lang.in 2011-08-05 17:48:26.0 +0200
+++
On 08/16/2011 01:08 PM, Arnaud Charlet wrote:
Please post them.
OK, here they are. FWIW, I have no idea how these changes will play with
libada (in particular the stamp-tools handling), so I suspect these changes
may require a bit of adjustment to be suitable.
Wouldn't you use these targets
Paolo,
On 08/10/2011 01:42 PM, Rainer Orth wrote:
* Centralize the determination of PICFLAG. Currently, three libraries
inside the gcc tree are built PIC without libtool: libgcc, libiberty,
and libgnat/libgnarl.
libiberty/configure.ac has a hardcoded list of PICFLAG that could be
On Mon, 2011-08-15 at 19:53 +0200, Rainer Orth wrote:
* For IA64 HP-UX, there's a claim that -fPIC is necessary despite PIC
code being the default. I could find no hint in trunk that this is
true any longer.
Rainer, If I recall correctly the issue for -fPIC on IA64 HP-UX is to
turn on
On 08/15/2011 10:53 AM, Rainer Orth wrote:
* The general approach between libtool and libiberty differs. Unless
otherwise specified (PIC is the default or doesn't work for some
reason), libtool defaults to -fPIC, while libiberty has a strange
mixture of -fPIC/-fpic and nothing, without
As has been mentioned before, one impediment to complete the toplevel
libgcc move is libada's use of TARGET_LIBGCC2_CFLAGS. AFAICS, it is
primarily used for gnatlib-*shared targets, so I assume that this was
done mostly (exclusively?) to get the flags necessary for PIC code
generation. Since
On 08/10/2011 01:42 PM, Rainer Orth wrote:
* Centralize the determination of PICFLAG. Currently, three libraries
inside the gcc tree are built PIC without libtool: libgcc, libiberty,
and libgnat/libgnarl.
libiberty/configure.ac has a hardcoded list of PICFLAG that could be
moved to
27 matches
Mail list logo
