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
DJ Delorie 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 official GCC
> 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 submit
Paolo Bonzini writes:
> On 08/19/2011 09:11 PM, Rainer Orth wrote:
>>
>> 2011-07-31 Rainer Orth
>>
>> config:
>> * picflag.m4: New file.
>>
>> gcc:
>> * configure.ac (GCC_PICFLAG_FOR_TARGET): Call it.
>> (PICFLAG_FOR_TARGET): Substitute.
>> * aclocal.m4: Regenerate.
On 08/19/2011 09:11 PM, Rainer Orth wrote:
2011-07-31 Rainer Orth
config:
* picflag.m4: New file.
gcc:
* configure.ac (GCC_PICFLAG_FOR_TARGET): Call it.
(PICFLAG_FOR_TARGET): Substitute.
* aclocal.m4: Regenerate.
* configure: Regenerate.
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
On Aug 18, 2011, at 10:03 AM, Rainer Orth wrote:
> Mike Stump 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 c
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 oka
Mike Stump 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.
Rainer
--
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.
> 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
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 wi
> 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
+++ gcc
> Sure, I was rather asking how make gnatlib (or whatever) is supposed to
> be invoked? From gcc/ada, any special needs?
>From /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
was r
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
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 resul
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
Arnaud Charlet 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 wouldn't be
> he
Paolo Bonzini 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
>>mixture
> 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 h
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
Arnaud Charlet 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 GCC_PICFLAG
> 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
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
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
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
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
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 thos
28 matches
Mail list logo
