public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: A config patch
@ 1997-08-29 10:00 Jason Merrill
  0 siblings, 0 replies; 14+ messages in thread
From: Jason Merrill @ 1997-08-29 10:00 UTC (permalink / raw)
  To: egcs

>>>>> Ian Lance Taylor <ian@cygnus.com> writes:

> I don't understand why it is important for [ -z "$PICFLAG" ] to
> succeed.  Irix 5 doesn't set PICFLAG, but I believe --enable-shared
> works nevertheless.

Yep, works for me.  It works on OSF/1, too.

Jason

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: A config patch
@ 1997-08-29  3:22 Ian Lance Taylor
  0 siblings, 0 replies; 14+ messages in thread
From: Ian Lance Taylor @ 1997-08-29  3:22 UTC (permalink / raw)
  To: egcs

   From: Richard Henderson <rth@cygnus.com>
   Date: Wed, 27 Aug 1997 01:13:46 -0700 (PDT)

   > --- /dev/null	Wed Dec 31 16:00:00 1969
   > +++ config/mh-alphapic	Mon Aug 25 18:42:20 1997
   > @@ -0,0 +1 @@
   > +PICFLAG=-fPIC

   This is incorrect for OSF/1 cc.  And, really, it has almost nil
   affect.  Better might be

   empty =
   PICFLAG=$(empty) $(empty)

   so that [ -z "$PICFLAG" ] succeeds.  But you would need to use
   libtool to think about getting OSF/1 shared libraries built --
   gcc -shared certainly doesn't work.

I don't understand why it is important for [ -z "$PICFLAG" ] to
succeed.  Irix 5 doesn't set PICFLAG, but I believe --enable-shared
works nevertheless.  On Irix 5, all files are compiled PIC by default.

Ian

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: HAVE_STDLIB_H
@ 1997-08-27 20:19 Joern Rennecke
  1997-08-27 20:19 ` A config patch Jason Merrill
  0 siblings, 1 reply; 14+ messages in thread
From: Joern Rennecke @ 1997-08-27 20:19 UTC (permalink / raw)
  To: egcs

> > Also, that will break on at least one system, StunOS, which (as I recall)
> > ends up having 'int free(char *)', and declares it in some header typically
> 
> I thought gcc fixincludes took care of it.

We are talking about gcc sources here.  To build stage1, you need to use
whatever compiler you have already installed - and use whatever header
files go with it.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: A config patch
@ 1997-08-27 17:40 Richard Henderson
  0 siblings, 0 replies; 14+ messages in thread
From: Richard Henderson @ 1997-08-27 17:40 UTC (permalink / raw)
  To: egcs

> And you also need to tell us why/how this library is correct if
> "gcc -shared" doesn't do the right thing on the alpha target.
> (IMHO) Building a broken libstdc++.so is worse than not building
> it at all.

The thing is that gcc -shared does do the right thing on alpha-elf,
but the problem with adding m?-alphapic is that it doesn't check what
operating system you are on, and so would break OSF/1 builds.  Which
we definitely do not want.


r~

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: A config patch
@ 1997-08-27 17:31 H.J. Lu
  0 siblings, 0 replies; 14+ messages in thread
From: H.J. Lu @ 1997-08-27 17:31 UTC (permalink / raw)
  To: egcs

> 
>   In message <m0x3iRL-0004efC@ocean.lucon.org>you write:
>   > > so that [ -z "$PICFLAG" ] succeeds.  But you would need to use
>   > > libtool to think about getting OSF/1 shared libraries built --
>   > > gcc -shared certainly doesn't work.
>   > > 
>   > 
>   > That may be true. But at least you can make libstdc++.so for
>   > alpha/ELF.
> The thing you need to explain is _why_ this particular patch enables
> you to build a shared libstdc++.  I don't have the time to grope
> around half a dozen makefiles and configure fragments to figure this
> out.  You've obviously done so, so please save everyone some time
> by providing this information.

[ -z "$PICFLAG" ] is used to create pic directory and piclist
which are used to build libstdc++.

> 
> And you also need to tell us why/how this library is correct if
> "gcc -shared" doesn't do the right thing on the alpha target.
> (IMHO) Building a broken libstdc++.so is worse than not building
> it at all.

--enable-shared is off by default. You have to use
--enable-shared to build libstdc++.so. If a broken
libstdc++.so is built, it is --enable-shared who is
broken.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: maintainer mode [was: Re: Building of generated parser files]
@ 1997-08-27 16:44 Ian Lance Taylor
  1997-08-27 16:44 ` A config patch Jeffrey A Law
  1997-08-27 16:44 ` Jeffrey A Law
  0 siblings, 2 replies; 14+ messages in thread
From: Ian Lance Taylor @ 1997-08-27 16:44 UTC (permalink / raw)
  To: egcs

   Date: 27 Aug 1997 14:08:27 +0200
   From: Samuel Tardieu <sam@inf.enst.fr>

   >>>>> "Ian" == Ian Lance Taylor <ian@cygnus.com> writes:

   Ian> I guess the main difficulty I see is the lack of a standard
   Ian> checksum program.  Everything else seems workable.

   Why not including a small one in the distribution, to be built soon enough?

That would lead us into a whole new set of problems, involving finding
a working compiler for the build system which can generate programs we
can execute.  Remember, we might be building with a cross compiler.
These problems are probably solvable, but at some point the solution
becomes worse than the disease.

Ian

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: A config patch
@ 1997-08-27 14:39 H.J. Lu
  0 siblings, 0 replies; 14+ messages in thread
From: H.J. Lu @ 1997-08-27 14:39 UTC (permalink / raw)
  To: egcs

> 
> > --- /dev/null	Wed Dec 31 16:00:00 1969
> > +++ config/mh-alphapic	Mon Aug 25 18:42:20 1997
> > @@ -0,0 +1 @@
> > +PICFLAG=-fPIC
> 
> This is incorrect for OSF/1 cc.  And, really, it has almost nil
> affect.  Better might be
> 
> empty =
> PICFLAG=$(empty) $(empty)
> 
> so that [ -z "$PICFLAG" ] succeeds.  But you would need to use
> libtool to think about getting OSF/1 shared libraries built --
> gcc -shared certainly doesn't work.
> 

That may be true. But at least you can make libstdc++.so for
alpha/ELF.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: A config patch
@ 1997-08-27  8:07 Richard Henderson
  0 siblings, 0 replies; 14+ messages in thread
From: Richard Henderson @ 1997-08-27  8:07 UTC (permalink / raw)
  To: egcs

> --- /dev/null	Wed Dec 31 16:00:00 1969
> +++ config/mh-alphapic	Mon Aug 25 18:42:20 1997
> @@ -0,0 +1 @@
> +PICFLAG=-fPIC

This is incorrect for OSF/1 cc.  And, really, it has almost nil
affect.  Better might be

empty =
PICFLAG=$(empty) $(empty)

so that [ -z "$PICFLAG" ] succeeds.  But you would need to use
libtool to think about getting OSF/1 shared libraries built --
gcc -shared certainly doesn't work.


r~

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: g77 configuring, docs (was Re: 970825 Snapshot Available)
@ 1997-08-27  6:19 Craig Burley
  1997-08-27  7:58 ` A config patch Jeffrey A Law
  0 siblings, 1 reply; 14+ messages in thread
From: Craig Burley @ 1997-08-27  6:19 UTC (permalink / raw)
  To: egcs

>I'm tempted to do both a gcc2 -> egcs and f77dev -> egcs merge
>as soon as we get the first release out the door.  I don't think
>we want to introduce too much new code this close to a release.

The patches to fix up the g77 docs are *very* safe, in case
you're wondering -- aside from deleting a gratuitous (and
non-conforming-in-ANSI-C ;-) comma after the last item in
an enum, they affect only the documentation, not the compiler
or the library.  (I'm referring to patches to intdoc.c, intrin.h,
the intdoc.in->intdoc.h renaming, and so on.)

Generally, the fixes I'm making to other parts of g77 are quite
safe too, because I have a release coming up in less than a week,
but only alpha testing and the release itself will "prove" just
how safe these fixes are.

One of the reasons I did the intdoc.in->intdoc.h change *now*,
instead of putting it off, is that I wanted to reduce the size
of future .diff files that would be needed to make the effective
rename.  g77 0.5.20 already had intdoc.h, it is true, but it
was quite small compared to the one pending for 0.5.21, which is
"full" (every single intrinsic documented!), so it seemed like
now was a worthwhile time to switch.

In the larger scale of egcs, I doubt this concern would amount
to much, as I expect the part of a future release->release patch
to rename intdoc.in to intdoc.h will amount to less than 1% of
the total patch.  ;-)

        tq vm, (burley)

^ permalink raw reply	[flat|nested] 14+ messages in thread
* A config patch
@ 1997-08-27  3:29 H.J. Lu
  0 siblings, 0 replies; 14+ messages in thread
From: H.J. Lu @ 1997-08-27  3:29 UTC (permalink / raw)
  To: egcs

A small patch for egcs.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
---
Mon Aug 25 17:31:49 1997  H.J. Lu  (hjl@gnu.ai.mit.edu)

	* mh-alphapic, mt-alphapic: New.

--- /dev/null	Wed Dec 31 16:00:00 1969
+++ config/mh-alphapic	Mon Aug 25 18:42:20 1997
@@ -0,0 +1 @@
+PICFLAG=-fPIC
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ config/mt-alphapic	Mon Aug 25 18:42:20 1997
@@ -0,0 +1 @@
+PICFLAG_FOR_TARGET=-fPIC

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~1997-09-07 14:30 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <u9hgc94d4p.fsf@yorick.cygnus.com>
1997-09-05 19:38 ` A config patch H.J. Lu
1997-09-07 14:11   ` Jeffrey A Law
1997-09-07 14:30     ` H.J. Lu
1997-08-29 10:00 Jason Merrill
  -- strict thread matches above, loose matches on Subject: below --
1997-08-29  3:22 Ian Lance Taylor
1997-08-27 20:19 HAVE_STDLIB_H Joern Rennecke
1997-08-27 20:19 ` A config patch Jason Merrill
1997-08-27 17:40 Richard Henderson
1997-08-27 17:31 H.J. Lu
1997-08-27 16:44 maintainer mode [was: Re: Building of generated parser files] Ian Lance Taylor
1997-08-27 16:44 ` A config patch Jeffrey A Law
1997-08-27 16:44 ` Jeffrey A Law
1997-08-27 14:39 H.J. Lu
1997-08-27  8:07 Richard Henderson
1997-08-27  6:19 g77 configuring, docs (was Re: 970825 Snapshot Available) Craig Burley
1997-08-27  7:58 ` A config patch Jeffrey A Law
1997-08-27  3:29 H.J. Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).