2 suggestions

[Ray Holme]

Firstly - I love your product and have used it for years.

I run on the Solaris Sparc platform mostly but use Linux and flavors of
Windows at times. My Sun is getting older so both of these suggestions
would help developers on less-than-super machines.

1) years ago GCC took about 2 hours to compile, last year it was 26 hours
for me, this year I just surpassed 48 hours and it is still going - it
would be very nice if one could compile the compiler and what it needs
without having to build the entire java set (yes I know it is bigger and
better, but don't need all the parts)

2) Much of the time is spent in the several iterations of building a
product doing the convfigure steps. These are repeated ad nauseum with the
results being obtained the hard way each time. As a database person, it
seems to me that by perhaps having a small database of configuration
learned things (perhaps 3 key strings and one result string separated by a
delimiter that awk recognizes) would allow the configuration to go much
faster. I would be happy to write a small shell script that extracts
information and another to add to such a database. The developer could
then point  the make at where this default file is located using an
environment variable - make and configure could use it and update it. Many
others are using your style configurations and could benefit from such a
database (gawk, gdb,  as well as many others that copy your excellent
style).

Thanks for doing a great job and making a superb product.

Ray Holme

Re: 2 suggestions

[Ray Holme]

Perhaps this is why I use /bin/sh for all scripts I write - tis leaner and
meaner by far.
Course it cannot do some things - but so far that has never been a problem.

Ray


Eric Botcazou <[EMAIL PROTECTED]> on Thursday, April 7, 2005 at
12:56 PM  wrote:


>> Not necessary.  If people would simply follow the directions here:
>>  by setting
>> CONFIG_SHELL to /bin/ksh before configure;make bootstrap, they
>> wouldn't have such insane build times.  I bet it cuts the 48 hours to
>> single digits.
>
>Sure, but libgcj build times have escalated, /bin/ksh or not /bin/ksh,
>and 
>they are getting unreasonable on (low-end) hardware currently sold by Sun.
>
>-- 
>Eric Botcazou
>

Re: 2 suggestions

[Ray Holme]

>Also it helps a lot to remove paths to directories over the network (like
>NFS)
>from PATH and LD_LIBRARY_PATH if this is possible.  Saves me half of
>bootstrap time with our crappy network setup here at university.
>

Old trick and highly relevent - but this sun mounts nothing NFS wise.

Thanks,

Ray

Re: 2 suggestions

[Ray Holme]

This is why I suggested several parameters to the question. Assumedly if
the parameters were the same, so would the answer be. Note that lots of
scripts do the same style confuring and a dictionary or param-set
responses was what I was suggesting.  It was merely a simple suggestion
and I believe it could work if used intelligently.

Best regards,

Ray


David Edelsohn <[EMAIL PROTECTED]> on Thursday, April 7, 2005 at 11:54 AM
 wrote:


>>>>>> Ray Holme writes:
>
>Ray> 2) Much of the time is spent in the several iterations of building a
>Ray> product doing the convfigure steps. These are repeated ad nauseum
>with the
>Ray> results being obtained the hard way each time. As a database person,
>it
>Ray> seems to me that by perhaps having a small database of configuration
>Ray> learned things (perhaps 3 key strings and one result string
>separated by a
>Ray> delimiter that awk recognizes) would allow the configuration to go
>much
>Ray> faster. I would be happy to write a small shell script that extracts
>Ray> information and another to add to such a database. The developer
>could
>Ray> then point  the make at where this default file is located using an
>Ray> environment variable - make and configure could use it and update
>it. Many
>Ray> others are using your style configurations and could benefit from
>such a
>Ray> database (gawk, gdb,  as well as many others that copy your
>excellent
>Ray> style).
>
>   As mentioned in another message, the user shell can contribute to
>a lot of the time.  Sometimes the default system shell is very inefficient
>and the configuration time could be improved by using GNU Bash.
>
>   Also, the configuration process may look repetitive, but the
>results might be different in each situation, so GCC needs to inquire
>conservatively.
>
>David
>

GCC 3.4.3

[Ray Holme]

Many thanks to all for the lessons on how NOT to make things you don't
want.

After 56 hours teh full make bootstrap finished - make install failed
miserable as
install.sh was not where it belonged - so I copied the SRCDIR install.sh
in and that made the top level installs work, but the sub-sub directories
were still looking for ../install-sh - so I copied it down another level

Thanks again.

Ray Holme

Re: GCC 3.4.3

[Ray Holme]

the install-sh is always referenced in the parent directory. 
(../install-sh)

so for all the first level directories in the install directory - one copy
at the top will do.

now for sub-sub directories - you must copy (or link) one into the parent
sub-directory.

I don't think there are any three level install directories (but don't
quote me).

Ray

libraries - double set

[Ray Holme]

After encountering problems with 3.4.3 of gcc (it did not compile a
package I really needed to have - yes yes I am sure it is right and
better, BUT ...), I went back to 3.3.3 for a while. I just noticed that
there are two copies of libraries installed the install script on my
machine (one in /opt/local/lib==/usr/local/lib) and one in
/opt/lib/sparcv9/==/usr/local/lib/sparcv9). They are installed by the same
install script as they are just about 1 minute apart in disk time
signatures but they are different in size by quite a bit. I did a little
more research and found lots of such things). Since some of these things
are quite large -

 What is the purpose of having two such identically names libraries?
  Or alternatively - which is the real one that I should be using?

The ones in /opt/lib are always larger! 
 And /opt/lib is the one mostly used for linking.
  SO, can I (should I) blow away the sparcv9 directory?

Confused,

Ray Holme

gcc 3.1.2 build on Solaris 2.9

[Ray Holme]

> Trying to get current (last build 3,3)  , I
installed
> texinfo 4.8 and make 2.81 first - I am using the
> following setup and make lines:
> 
> SRC=/local/src/gnu/gcc-4.1.2; CONFIG_SHELL=/bin/ksh
> $SRC/configure --without-fast-fixincludes
--enable-languages=c,c++,java
> make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g
> -O2 -fno-implicit-templates' bootstrap
> 
> Mostly the make seems to work but constantly whines
> about missing makeinfo and a retry (quickstrap) 
> yields this at the end
> 
> WARNING: `makeinfo' is missing on your system.  You
> should only need it if
>  you modified a `.texi' or `.texinfo' file,
> or
> any other file
>  indirectly affecting the aspect of the
> manual.  The spurious
>  call might also be the consequence of using
> a
> buggy `make' (AIX,
>  DU, IRIX).  You might want to install the
> `Texinfo' package or
>  the `GNU make' package.  Grab either from
> any
> GNU archive site.
> make[4]: *** [fastjar.info] Error 1
> make[4]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build/fastjar'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build/fastjar'
> make[2]: *** [all-fastjar] Error 2
> make[2]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build'
> make: *** [quickstrap] Error 2
> 
> I never had problems with prior releases - even
> without texinfo and an earlier version of make.
> 
> What the sam hill am I doing wrong?
> 
> Ray



   

Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

Fwd: gcc 3.1.2 build on Solaris 2.9 - success

[Ray Holme]

OK 

I had make 2.81 installed from the get-go and it did
not conform to the "smart" make, but the first time I
tried to fix by installing texinfo just before "make
install" - NFG.

I installed texinfo and rebuilt the world - it worked.

Thanks - and yes I will do my bit to support GNU as
soon as it is possible..

Ray

--- Ray Holme <[EMAIL PROTECTED]> wrote:

> Date: Sat, 9 Jun 2007 04:29:57 -0700 (PDT)
> From: Ray Holme <[EMAIL PROTECTED]>
> Subject: gcc 3.1.2 build on Solaris 2.9
> To: [EMAIL PROTECTED]
> 
> Trying to get current (last build 3,3)  , I
> installed
> texinfo 4.8 and make 2.81 first - I am using the
> following make line:
> 
> make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g
> -O2 -fno-implicit-templates' bootstrap
> 
> Mostly the make seems to work but constantly whines
> about missing makeinfo and a retry (quickstrap) 
> yields this at the end
> 
> WARNING: `makeinfo' is missing on your system.  You
> should only need it if
>  you modified a `.texi' or `.texinfo' file,
> or
> any other file
>  indirectly affecting the aspect of the
> manual.  The spurious
>  call might also be the consequence of using
> a
> buggy `make' (AIX,
>  DU, IRIX).  You might want to install the
> `Texinfo' package or
>  the `GNU make' package.  Grab either from
> any
> GNU archive site.
> make[4]: *** [fastjar.info] Error 1
> make[4]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build/fastjar'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build/fastjar'
> make[2]: *** [all-fastjar] Error 2
> make[2]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/spare/disk4/lots_src/gnu/gcc_build'
> make: *** [quickstrap] Error 2
> 
> I never had problems with prior releases - even
> without texinfo and an earlier version of make.
> 
> What the sam hill am I doing wrong?
> 
> Ray
> 
> 
>
>

> Be a better Globetrotter. Get better travel answers
> from someone who knows. Yahoo! Answers - Check it
> out.
>
http://answers.yahoo.com/dir/?link=list&sid=396545469
> 



 

Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/