Re: why does g77 build?

Re: why does g77 build?

[Alexader V. Voinov]

Alex Buell <alex.buell@tahallah.demon.co.uk> wrote:

> On 17 Apr 1999 craig@jcb-sc.com wrote:
>
> > >When I returned to my screen I noticed that g77 was being built.
> > >I didn't want to build g77.  The only compilers I want are the
> > >C and C++ ones.
> >
> > Use the LANGUAGES macro instead.  I hope we fix, if we haven't
> > already, --enable-languages for egcs 1.2, though....
>
> Tee-hee. Another one bitten by this (I got bit by this one 2 days
ago!).
> Yes, please do fix it for 1.2 so we can just enable the bits we want.
I
> think this system of doing things like this is MUCH more convienent
and
> easier to memorize.

Please fix also unnecessary build of 'libf2c' when no 'f77' in
LANGUAGES is specified. I caught it when built a crosscompiler for
i386-*-vxworks target.
(The problem was that for libf2c 'configure' failed at some point, but
that's another story...)

Alexander

Re: why does g77 build?

[craig]

>Alex Buell <alex.buell@tahallah.demon.co.uk> wrote:
>
>> On 17 Apr 1999 craig@jcb-sc.com wrote:
>>
>> > >When I returned to my screen I noticed that g77 was being built.
>> > >I didn't want to build g77.  The only compilers I want are the
>> > >C and C++ ones.
>> >
>> > Use the LANGUAGES macro instead.  I hope we fix, if we haven't
>> > already, --enable-languages for egcs 1.2, though....
>>
>> Tee-hee. Another one bitten by this (I got bit by this one 2 days
>ago!).
>> Yes, please do fix it for 1.2 so we can just enable the bits we want.
>I
>> think this system of doing things like this is MUCH more convienent
>and
>> easier to memorize.
>
>Please fix also unnecessary build of 'libf2c' when no 'f77' in
>LANGUAGES is specified. I caught it when built a crosscompiler for
>i386-*-vxworks target.
>(The problem was that for libf2c 'configure' failed at some point, but
>that's another story...)

As far as I can tell, it already works, in the development snapshots.
I just tried configuring --enable-languages=c, then building via
a straight build, and hardly anything Fortran-like happened, except:

Configuring in i686-pc-linux-gnu/libf2c
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking if compiler f771 has been built... no

Now, were you saying that the *development* version of egcs still
failed for you in this area, or that version 1.1.2 did?  If the
former, please submit a bug report; if the latter, that's because
--enable-languages apparently wasn't supported in that version.

So, I consider this issue closed for now, as things appear to be
working correctly.

BTW, I agree that it's better to put things like this at the configuration
step.  In fact, I think we're going to have to put specifying the
compiler there, and whether a bootstrap-build vs. straight-build is
desired there, as well, when we re-work the configury mess.

        tq vm, (burley)

Re: why does g77 build?

[patrick]

Hello,


Sometime in the late 1900s it was said:

> >Alex Buell <alex.buell@tahallah.demon.co.uk> wrote:
> >
> >> On 17 Apr 1999 craig@jcb-sc.com wrote:
> >>
> >> > >When I returned to my screen I noticed that g77 was being built.
> >> > >I didn't want to build g77.  The only compilers I want are the
> >> > >C and C++ ones.
> >> >
> >> > Use the LANGUAGES macro instead.  I hope we fix, if we haven't
> >> > already, --enable-languages for egcs 1.2, though....

[dd]

> As far as I can tell, it already works, in the development snapshots.
> I just tried configuring --enable-languages=c, then building via
> a straight build, and hardly anything Fortran-like happened, except:

[dd]

> Now, were you saying that the *development* version of egcs still
> failed for you in this area, or that version 1.1.2 did?  If the
> former, please submit a bug report; if the latter, that's because
> --enable-languages apparently wasn't supported in that version.
> 
> So, I consider this issue closed for now, as things appear to be
> working correctly.


   --enable-languages did not work on the 1.1.2 version.  I was mis-
   lead by the documentation available on egcs's website.  There was
   no mention that this option was for the development snapshots only.
   I thank everyone who took the time to point this out to me.

   One thing I want to mention regarding 'make uninstall' and the lack
   of it.  I read the archives of this list and noticed the long and
   unresolved discussion on it and didn't want to bring it up again :)
   But since I'm replying to this post I'll just ask if it would be
   too terribly hard to have the ./configure setup a Makefile that
   would "spit" out a shell script (uninstall.sh) after 'make install'
   completes that would have a list similar to this:

      rm -f $(prefix)/egcs-stuff-that-got-installed-1
      rm -f $(prefix)/egcs-stuff-that-got-installed-2
      ...
      rm -f $(prefix)/egcs-stuff-that-got-installed-n

   Basically an rm list of all the files it installed.  So then the user
   wouldn't need to keep the src-tree for uninstalling it for the next
   release.  Just keep the script to run at a later time.

   I am not too familiar with ./configure.  I have looked at it at
   times and been discouraged to look further.  So I don't know how
   it exactly works to play with it.

   Any thoughts/comments about this?  (I really hope that this doesn't
   start another huge thread that branches into the different distro
   package managers etc etc.)
   
   I'll shutup since I know there is more interesting and more
   important things discussed in this list and appologize if I'm
   wasting other's time with "user" concerns here.


> BTW, I agree that it's better to put things like this at the configuration
> step.  In fact, I think we're going to have to put specifying the
> compiler there, and whether a bootstrap-build vs. straight-build is
> desired there, as well, when we re-work the configury mess.


   Hmm... I couldn't find much documentation about bootstrap-build
   vs. straight-build in the docs I found on egcs's site.  So I just
   did what the install/configure docs told me to do 'make bootstarp-lean'.

   Could someone clearify these two for newbies like me.  Would
   the make target for the 'straight-build' just be:

      LANGUAGES="c,c++,etc" make

   or is there more to it?


Thanks once again for the info,

      patrick@boxsoft.com

Re: why does g77 build?

[craig]

>   Could someone clearify these two for newbies like me.  Would
>   the make target for the 'straight-build' just be:
>
>      LANGUAGES="c,c++,etc" make
>
>   or is there more to it?

I think that would work, except for the lack of support for the "etc"
language.  :)

But if you want to avoid libf2c, for example, getting built, start off
with "rm -fr egcs-1.1.2/libf2c" or something like that -- I forget
the recipe others have posted.

        tq vm, (burley)

Re: why does g77 build?

[craig]

>   But since I'm replying to this post I'll just ask if it would be
>   too terribly hard to have the ./configure setup a Makefile that
>   would "spit" out a shell script (uninstall.sh) after 'make install'
>   completes that would have a list similar to this:
>
>      rm -f $(prefix)/egcs-stuff-that-got-installed-1
>      rm -f $(prefix)/egcs-stuff-that-got-installed-2
>      ...
>      rm -f $(prefix)/egcs-stuff-that-got-installed-n
>
>   Basically an rm list of all the files it installed.  So then the user
>   wouldn't need to keep the src-tree for uninstalling it for the next
>   release.  Just keep the script to run at a later time.

I'm 100% in favor of that.  Wish all software worked that way.  But
it is, as you noticed when looking at the source, something that
would require a nearly complete redesign of how installations are
done, from the top (the GNU approach) on down.

In the meantime, a feasible solution is to always configure to install
into a unique tree, then substitute "rm -fr $(unique-prefix)" for
running the shell script you and I want spat out by the install.
(I use this approach to manage development snapshots, multiple FSF/EGCS
releases of gcc, etc.  It works quite well.)

        tq vm, (burley)

Re: why does g77 build?

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    >> But since I'm replying to this post I'll just ask if it would
    >> be too terribly hard to have the ./configure setup a Makefile
    >> that would "spit" out a shell script (uninstall.sh) after 'make
    >> install' completes that would have a list similar to this:
    >> 
    >> rm -f $(prefix)/egcs-stuff-that-got-installed-1 rm -f
    >> $(prefix)/egcs-stuff-that-got-installed-2 ...  rm -f
    >> $(prefix)/egcs-stuff-that-got-installed-n
    >> 
    >> Basically an rm list of all the files it installed.  So then
    >> the user wouldn't need to keep the src-tree for uninstalling it
    >> for the next release.  Just keep the script to run at a later
    >> time.

    craig> I'm 100% in favor of that.  Wish all software worked that
    craig> way.  But it is, as you noticed when looking at the source,
    craig> something that would require a nearly complete redesign of
    craig> how installations are done, from the top (the GNU approach)
    craig> on down.

    craig> In the meantime, a feasible solution is to always configure
    craig> to install into a unique tree, then substitute "rm -fr
    craig> $(unique-prefix)" for running the shell script you and I
    craig> want spat out by the install.  (I use this approach to
    craig> manage development snapshots, multiple FSF/EGCS releases of
    craig> gcc, etc.  It works quite well.)

I find GNU stow very useful for this kind of thing.  It's available on
prep.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: why does g77 build?

[Jeffrey A Law]

  In message < 19990425125723.8671.qmail@deer >you write:
  > >   But since I'm replying to this post I'll just ask if it would be
  > >   too terribly hard to have the ./configure setup a Makefile that
  > >   would "spit" out a shell script (uninstall.sh) after 'make install'
  > >   completes that would have a list similar to this:
  > >
  > >      rm -f $(prefix)/egcs-stuff-that-got-installed-1
  > >      rm -f $(prefix)/egcs-stuff-that-got-installed-2
  > >      ...
  > >      rm -f $(prefix)/egcs-stuff-that-got-installed-n
  > >
  > >   Basically an rm list of all the files it installed.  So then the user
  > >   wouldn't need to keep the src-tree for uninstalling it for the next
  > >   release.  Just keep the script to run at a later time.
  > 
  > I'm 100% in favor of that.  Wish all software worked that way.  But
  > it is, as you noticed when looking at the source, something that
  > would require a nearly complete redesign of how installations are
  > done, from the top (the GNU approach) on down.
Fixing up the "make uninstall" is also on my (mental) todo list for the
post-1.2 configure/make reorganization.

Looking further down the road, some kind of package management system would be
the obvious next step.  The trick is to settle on one (I don't think we want
to try and support the various packaging systems one finds these days).  The
other trick is how to make the package management system play with sites that
want to install multiple compilers (ie, a native, then one or more cross
compilers).

jeff

Re: why does g77 build?

[Jeffrey A Law]

  In message < 19990425125723.8671.qmail@deer >you write:
  > >   But since I'm replying to this post I'll just ask if it would be
  > >   too terribly hard to have the ./configure setup a Makefile that
  > >   would "spit" out a shell script (uninstall.sh) after 'make install'
  > >   completes that would have a list similar to this:
  > >
  > >      rm -f $(prefix)/egcs-stuff-that-got-installed-1
  > >      rm -f $(prefix)/egcs-stuff-that-got-installed-2
  > >      ...
  > >      rm -f $(prefix)/egcs-stuff-that-got-installed-n
  > >
  > >   Basically an rm list of all the files it installed.  So then the user
  > >   wouldn't need to keep the src-tree for uninstalling it for the next
  > >   release.  Just keep the script to run at a later time.
  > 
  > I'm 100% in favor of that.  Wish all software worked that way.  But
  > it is, as you noticed when looking at the source, something that
  > would require a nearly complete redesign of how installations are
  > done, from the top (the GNU approach) on down.
Fixing up the "make uninstall" is also on my (mental) todo list for the
post-1.2 configure/make reorganization.

Looking further down the road, some kind of package management system would be
the obvious next step.  The trick is to settle on one (I don't think we want
to try and support the various packaging systems one finds these days).  The
other trick is how to make the package management system play with sites that
want to install multiple compilers (ie, a native, then one or more cross
compilers).

jeff

Re: why does g77 build?

[craig]

>   But since I'm replying to this post I'll just ask if it would be
>   too terribly hard to have the ./configure setup a Makefile that
>   would "spit" out a shell script (uninstall.sh) after 'make install'
>   completes that would have a list similar to this:
>
>      rm -f $(prefix)/egcs-stuff-that-got-installed-1
>      rm -f $(prefix)/egcs-stuff-that-got-installed-2
>      ...
>      rm -f $(prefix)/egcs-stuff-that-got-installed-n
>
>   Basically an rm list of all the files it installed.  So then the user
>   wouldn't need to keep the src-tree for uninstalling it for the next
>   release.  Just keep the script to run at a later time.

I'm 100% in favor of that.  Wish all software worked that way.  But
it is, as you noticed when looking at the source, something that
would require a nearly complete redesign of how installations are
done, from the top (the GNU approach) on down.

In the meantime, a feasible solution is to always configure to install
into a unique tree, then substitute "rm -fr $(unique-prefix)" for
running the shell script you and I want spat out by the install.
(I use this approach to manage development snapshots, multiple FSF/EGCS
releases of gcc, etc.  It works quite well.)

        tq vm, (burley)

Re: why does g77 build?

[Alexader V. Voinov]

Alex Buell <alex.buell@tahallah.demon.co.uk> wrote:

> On 17 Apr 1999 craig@jcb-sc.com wrote:
>
> > >When I returned to my screen I noticed that g77 was being built.
> > >I didn't want to build g77.  The only compilers I want are the
> > >C and C++ ones.
> >
> > Use the LANGUAGES macro instead.  I hope we fix, if we haven't
> > already, --enable-languages for egcs 1.2, though....
>
> Tee-hee. Another one bitten by this (I got bit by this one 2 days
ago!).
> Yes, please do fix it for 1.2 so we can just enable the bits we want.
I
> think this system of doing things like this is MUCH more convienent
and
> easier to memorize.

Please fix also unnecessary build of 'libf2c' when no 'f77' in
LANGUAGES is specified. I caught it when built a crosscompiler for
i386-*-vxworks target.
(The problem was that for libf2c 'configure' failed at some point, but
that's another story...)

Alexander

Re: why does g77 build?

[craig]

>   Could someone clearify these two for newbies like me.  Would
>   the make target for the 'straight-build' just be:
>
>      LANGUAGES="c,c++,etc" make
>
>   or is there more to it?

I think that would work, except for the lack of support for the "etc"
language.  :)

But if you want to avoid libf2c, for example, getting built, start off
with "rm -fr egcs-1.1.2/libf2c" or something like that -- I forget
the recipe others have posted.

        tq vm, (burley)

Re: why does g77 build?

[patrick]

Hello,


Sometime in the late 1900s it was said:

> >Alex Buell <alex.buell@tahallah.demon.co.uk> wrote:
> >
> >> On 17 Apr 1999 craig@jcb-sc.com wrote:
> >>
> >> > >When I returned to my screen I noticed that g77 was being built.
> >> > >I didn't want to build g77.  The only compilers I want are the
> >> > >C and C++ ones.
> >> >
> >> > Use the LANGUAGES macro instead.  I hope we fix, if we haven't
> >> > already, --enable-languages for egcs 1.2, though....

[dd]

> As far as I can tell, it already works, in the development snapshots.
> I just tried configuring --enable-languages=c, then building via
> a straight build, and hardly anything Fortran-like happened, except:

[dd]

> Now, were you saying that the *development* version of egcs still
> failed for you in this area, or that version 1.1.2 did?  If the
> former, please submit a bug report; if the latter, that's because
> --enable-languages apparently wasn't supported in that version.
> 
> So, I consider this issue closed for now, as things appear to be
> working correctly.


   --enable-languages did not work on the 1.1.2 version.  I was mis-
   lead by the documentation available on egcs's website.  There was
   no mention that this option was for the development snapshots only.
   I thank everyone who took the time to point this out to me.

   One thing I want to mention regarding 'make uninstall' and the lack
   of it.  I read the archives of this list and noticed the long and
   unresolved discussion on it and didn't want to bring it up again :)
   But since I'm replying to this post I'll just ask if it would be
   too terribly hard to have the ./configure setup a Makefile that
   would "spit" out a shell script (uninstall.sh) after 'make install'
   completes that would have a list similar to this:

      rm -f $(prefix)/egcs-stuff-that-got-installed-1
      rm -f $(prefix)/egcs-stuff-that-got-installed-2
      ...
      rm -f $(prefix)/egcs-stuff-that-got-installed-n

   Basically an rm list of all the files it installed.  So then the user
   wouldn't need to keep the src-tree for uninstalling it for the next
   release.  Just keep the script to run at a later time.

   I am not too familiar with ./configure.  I have looked at it at
   times and been discouraged to look further.  So I don't know how
   it exactly works to play with it.

   Any thoughts/comments about this?  (I really hope that this doesn't
   start another huge thread that branches into the different distro
   package managers etc etc.)
   
   I'll shutup since I know there is more interesting and more
   important things discussed in this list and appologize if I'm
   wasting other's time with "user" concerns here.


> BTW, I agree that it's better to put things like this at the configuration
> step.  In fact, I think we're going to have to put specifying the
> compiler there, and whether a bootstrap-build vs. straight-build is
> desired there, as well, when we re-work the configury mess.


   Hmm... I couldn't find much documentation about bootstrap-build
   vs. straight-build in the docs I found on egcs's site.  So I just
   did what the install/configure docs told me to do 'make bootstarp-lean'.

   Could someone clearify these two for newbies like me.  Would
   the make target for the 'straight-build' just be:

      LANGUAGES="c,c++,etc" make

   or is there more to it?


Thanks once again for the info,

      patrick@boxsoft.com

Re: why does g77 build?

[craig]

>Alex Buell <alex.buell@tahallah.demon.co.uk> wrote:
>
>> On 17 Apr 1999 craig@jcb-sc.com wrote:
>>
>> > >When I returned to my screen I noticed that g77 was being built.
>> > >I didn't want to build g77.  The only compilers I want are the
>> > >C and C++ ones.
>> >
>> > Use the LANGUAGES macro instead.  I hope we fix, if we haven't
>> > already, --enable-languages for egcs 1.2, though....
>>
>> Tee-hee. Another one bitten by this (I got bit by this one 2 days
>ago!).
>> Yes, please do fix it for 1.2 so we can just enable the bits we want.
>I
>> think this system of doing things like this is MUCH more convienent
>and
>> easier to memorize.
>
>Please fix also unnecessary build of 'libf2c' when no 'f77' in
>LANGUAGES is specified. I caught it when built a crosscompiler for
>i386-*-vxworks target.
>(The problem was that for libf2c 'configure' failed at some point, but
>that's another story...)

As far as I can tell, it already works, in the development snapshots.
I just tried configuring --enable-languages=c, then building via
a straight build, and hardly anything Fortran-like happened, except:

Configuring in i686-pc-linux-gnu/libf2c
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking if compiler f771 has been built... no

Now, were you saying that the *development* version of egcs still
failed for you in this area, or that version 1.1.2 did?  If the
former, please submit a bug report; if the latter, that's because
--enable-languages apparently wasn't supported in that version.

So, I consider this issue closed for now, as things appear to be
working correctly.

BTW, I agree that it's better to put things like this at the configuration
step.  In fact, I think we're going to have to put specifying the
compiler there, and whether a bootstrap-build vs. straight-build is
desired there, as well, when we re-work the configury mess.

        tq vm, (burley)

Re: why does g77 build?

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    >> But since I'm replying to this post I'll just ask if it would
    >> be too terribly hard to have the ./configure setup a Makefile
    >> that would "spit" out a shell script (uninstall.sh) after 'make
    >> install' completes that would have a list similar to this:
    >> 
    >> rm -f $(prefix)/egcs-stuff-that-got-installed-1 rm -f
    >> $(prefix)/egcs-stuff-that-got-installed-2 ...  rm -f
    >> $(prefix)/egcs-stuff-that-got-installed-n
    >> 
    >> Basically an rm list of all the files it installed.  So then
    >> the user wouldn't need to keep the src-tree for uninstalling it
    >> for the next release.  Just keep the script to run at a later
    >> time.

    craig> I'm 100% in favor of that.  Wish all software worked that
    craig> way.  But it is, as you noticed when looking at the source,
    craig> something that would require a nearly complete redesign of
    craig> how installations are done, from the top (the GNU approach)
    craig> on down.

    craig> In the meantime, a feasible solution is to always configure
    craig> to install into a unique tree, then substitute "rm -fr
    craig> $(unique-prefix)" for running the shell script you and I
    craig> want spat out by the install.  (I use this approach to
    craig> manage development snapshots, multiple FSF/EGCS releases of
    craig> gcc, etc.  It works quite well.)

I find GNU stow very useful for this kind of thing.  It's available on
prep.

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

why does g77 build?

[patrick]

Hello,

I downloaded egcs 1.1.2 today to upgrade my work (and later my home) system:

Linux drvi 2.0.34 #2 Fri Sep 25 11:01:49 PDT 1998 i586 unknown

drvi:/usr/local/src/egcs-112-objdir% gcc -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)


I followed the direction on  egcs.cygnus.com/install/configure.html

The build went fine.  No errors that were apparent to me (not that
stared at my screen the entire time the build was happening -- I
took off for lunch after a while).

When I returned to my screen I noticed that g77 was being built.
I didn't want to build g77.  The only compilers I want are the
C and C++ ones.

The Configure instructions mention that the option

   --enable-languages=lang1,lang2,...,langn

could be used to only build a subset of available compilers.  It
mentions that currently the only available choices are:

   CHILL, c++, f77, java and objc.

and to get a list of valid values of langx to `cd gcc` and:

   grep language= */config-lang.in

this gives me the following:

gcc/cp/config-lang.in:language="c++"
gcc/f/config-lang.in:language="f77"
gcc/objc/config-lang.in:language="objc"

I noticed that 'java' was not available while the instructions
seem to indicate that it is.  So i included it in my --enable-languages=
option to configure just to see what will happen.

The following is a paste of my config.status file which shows this
option:

-- config.status begin
#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
../egcs-1.1.2/configure --with-gcc-version-trigger=/usr/local/src/egcs-1.1.2/gcc
/version.c --host=i586-pc-linux-gnulibc1 --enable-shared --enable-languages=c++,
java --enable-threads --enable-threads=posix --norecursion
# using "mh-frag" and "mt-frag"
-- config.status end


I looked through the egcs and egcs-bugs archives on the site to see
if there is an answer why the g77 would be built but I was unable to
find anything by scrolling through the list of subjects (even read
a few posts that seem to have potential).

Am I doing something wrong?  How can I prevent the g77 from being built.
I have no need for it.  And although I currently have no  need for java
compiler ... I'm curious to find out if it is available and how to get
it to build (obviously the src is not included in the egcs-1.1.2.tar.gz).

Since i am in the asking mode one last question.  I have LinuxThreads 0.6
installed on my Linux boxes.  Is this threads package considered a valid
candidate for --enable-threads option?


I'd appreciate either info or directions to documentation regarding these
concerns.

Thanks in advance for any help offered,

         patrick@boxsoft.com
         sidster@drink.com


ps. Not including the 'java' option to --enable-languages= list produces
    the same result (ie. builds the g77 compiler).

Re: why does g77 build?

[craig]

>When I returned to my screen I noticed that g77 was being built.
>I didn't want to build g77.  The only compilers I want are the
>C and C++ ones.

Use the LANGUAGES macro instead.  I hope we fix, if we haven't
already, --enable-languages for egcs 1.2, though....

        tq vm, (burley)

Re: why does g77 build?

[Jeffrey A Law]

  In message < 199904170019.RAA11303@3eye.boxsoft.com >you write:
  > 
  > I downloaded egcs 1.1.2 today to upgrade my work (and later my home) system
[ ... ]
  > The Configure instructions mention that the option
  > 
  >    --enable-languages=lang1,lang2,...,langn
That option is only available in the current development snapshots
(which will become egcs-1.2).

Apparently the documentation isn't clear on that point.

jeff

Re: why does g77 build?

[Alex Buell]

On 17 Apr 1999 craig@jcb-sc.com wrote:

> >When I returned to my screen I noticed that g77 was being built.
> >I didn't want to build g77.  The only compilers I want are the
> >C and C++ ones.
> 
> Use the LANGUAGES macro instead.  I hope we fix, if we haven't
> already, --enable-languages for egcs 1.2, though....

Tee-hee. Another one bitten by this (I got bit by this one 2 days ago!).
Yes, please do fix it for 1.2 so we can just enable the bits we want. I
think this system of doing things like this is MUCH more convienent and
easier to memorize.

Cheers, 
Alex 
-- 
"A mind opened by new ideas can never return to its original limits"

Re: why does g77 build?

[Jeffrey A Law]

  In message < 199904170019.RAA11303@3eye.boxsoft.com >you write:
  > 
  > I downloaded egcs 1.1.2 today to upgrade my work (and later my home) system
[ ... ]
  > The Configure instructions mention that the option
  > 
  >    --enable-languages=lang1,lang2,...,langn
That option is only available in the current development snapshots
(which will become egcs-1.2).

Apparently the documentation isn't clear on that point.

jeff

Re: why does g77 build?

[Alex Buell]

On 17 Apr 1999 craig@jcb-sc.com wrote:

> >When I returned to my screen I noticed that g77 was being built.
> >I didn't want to build g77.  The only compilers I want are the
> >C and C++ ones.
> 
> Use the LANGUAGES macro instead.  I hope we fix, if we haven't
> already, --enable-languages for egcs 1.2, though....

Tee-hee. Another one bitten by this (I got bit by this one 2 days ago!).
Yes, please do fix it for 1.2 so we can just enable the bits we want. I
think this system of doing things like this is MUCH more convienent and
easier to memorize.

Cheers, 
Alex 
-- 
"A mind opened by new ideas can never return to its original limits"

Re: why does g77 build?

[craig]

>When I returned to my screen I noticed that g77 was being built.
>I didn't want to build g77.  The only compilers I want are the
>C and C++ ones.

Use the LANGUAGES macro instead.  I hope we fix, if we haven't
already, --enable-languages for egcs 1.2, though....

        tq vm, (burley)

why does g77 build?

[patrick]

Hello,

I downloaded egcs 1.1.2 today to upgrade my work (and later my home) system:

Linux drvi 2.0.34 #2 Fri Sep 25 11:01:49 PDT 1998 i586 unknown

drvi:/usr/local/src/egcs-112-objdir% gcc -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)


I followed the direction on  egcs.cygnus.com/install/configure.html

The build went fine.  No errors that were apparent to me (not that
stared at my screen the entire time the build was happening -- I
took off for lunch after a while).

When I returned to my screen I noticed that g77 was being built.
I didn't want to build g77.  The only compilers I want are the
C and C++ ones.

The Configure instructions mention that the option

   --enable-languages=lang1,lang2,...,langn

could be used to only build a subset of available compilers.  It
mentions that currently the only available choices are:

   CHILL, c++, f77, java and objc.

and to get a list of valid values of langx to `cd gcc` and:

   grep language= */config-lang.in

this gives me the following:

gcc/cp/config-lang.in:language="c++"
gcc/f/config-lang.in:language="f77"
gcc/objc/config-lang.in:language="objc"

I noticed that 'java' was not available while the instructions
seem to indicate that it is.  So i included it in my --enable-languages=
option to configure just to see what will happen.

The following is a paste of my config.status file which shows this
option:

-- config.status begin
#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
../egcs-1.1.2/configure --with-gcc-version-trigger=/usr/local/src/egcs-1.1.2/gcc
/version.c --host=i586-pc-linux-gnulibc1 --enable-shared --enable-languages=c++,
java --enable-threads --enable-threads=posix --norecursion
# using "mh-frag" and "mt-frag"
-- config.status end


I looked through the egcs and egcs-bugs archives on the site to see
if there is an answer why the g77 would be built but I was unable to
find anything by scrolling through the list of subjects (even read
a few posts that seem to have potential).

Am I doing something wrong?  How can I prevent the g77 from being built.
I have no need for it.  And although I currently have no  need for java
compiler ... I'm curious to find out if it is available and how to get
it to build (obviously the src is not included in the egcs-1.1.2.tar.gz).

Since i am in the asking mode one last question.  I have LinuxThreads 0.6
installed on my Linux boxes.  Is this threads package considered a valid
candidate for --enable-threads option?


I'd appreciate either info or directions to documentation regarding these
concerns.

Thanks in advance for any help offered,

         patrick@boxsoft.com
         sidster@drink.com


ps. Not including the 'java' option to --enable-languages= list produces
    the same result (ie. builds the g77 compiler).