Douglas Wade Needham <cinnion@ka8zrt.com> writes:
> My latest pkgsrc build, with pkgsrc updated to a Jan 12 (from the
> trunk), completed in 99304 seconds.  Same base 3.0 build (so same

As I said... WHAT VERSION OF THE COMPILER. Newer versions of gcc are
dramatically slower.

Perry

> compiler, kernel, etc.) on a machine with no other changes outside of
> a reboot and that update.  But since the build which took forever was
> done after a reboot as well, so I would tend to discount the reboot,
> and I am just left wondering what was happening.  I still have the log
> files to go over, which include the time taken for each entry in my
> package list, so perhaps something will stand out there, but I guess
> this is just something for which we need to keep an eye out.  I know
> given a few updates to pkgsrc (such as my missing devel/swig13 being
> removed) will have me doing yet another build after I review this
> latest log, so if folks are interested, I will post what I see there
> as well.
>
> - Doug
>
> Quoting Perry E. Metzger (perry@piermont.com):
>> 
>> Douglas Wade Needham <cinnion@ka8zrt.com> writes:
>> > Greetings John, and the rest of the NetBSD community,
>> >
>> > I don't think it is just the sun3 port.  I did a build of a set of
>> > pkgsrc packages about three weeks ago with a 2.1.0 kernel, and the
>> > build took 76913 seconds.  Then, I noticed that 3.0 was available, and
>> > after making changes to my build wrapper scripts, building 3.0 into my
>> > sandbox, and upgrading to the 3.0 kernel, I started the same exact
>> > build for 3.0, and the build is still going after 186920 seconds!!!
>> 
>> Compare the gcc versions in both releases. If I remember correctly,
>> there was an "upgrade", resulting in much longer compile times. (Every
>> version of gcc seems much slower than the last.)
>> 
>> Perry
>
> -- 
> Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
> Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
> Disclaimer: My opinions are my own.  Since I don't want them, why
>             should my employer, or anybody else for that matter! 
>

-- 
Perry E. Metzger		perry@piermont.com