Re: wip/gcc45: test results on NetBSD

["Kai-Uwe Eckhardt" <kuehro%gmx.de@localhost>]

Hi, Aleksej,

first I will try to answer your questions and then I will spend
some words on the future of this package. Sorry, if it gets a bit
longer than a few lines, but we need a good strategy.

> I need gcc>=4.3 for work nowadays, thus I'll look more at fixing these
> two packages.

Everybody needs a newer gcc, because bugs won't be fixed any longer
by the gcc team, or one has to backport fixes. And the Fortran
standard has evolved rather quickly. For my newer codes even 4.4 is
useless.

> I still cannot build lang/gcc44, and am able to build wip/gcc45 only on
> one system of four at hand today.

Which system works and which do not ?
lang/gcc44 has been taken over by a new maintainer and he has just
updated it to 4.4.5 but my patches have yet to be evaluated and
integrated. Have yout tried the patches I send to pkgsrc-bugs
pkg/44598 on Feb 23 (patches for NetBSD in patch form) ?
I only use NetBSD from time to time but I was shocked that gcc44
won't compile at all due to bugs in gfortran, g++ and java. I
built gfortran 4.5 and 4.6 several times and it worked fine with lapack
and gave the same results with one simulation package compared to
lots of other compilers and platforms (only F77).

> (Could it be that lang/gcc44 and wip/gcc45 interact with installed
> packages?
> Perhaps something I don't have installed and you do.)

Yes, for instance gcc uses gawk and gsed if installed. The Makefile
tries to force the use of the local sed and gawk does not seem to make
a difference.

To compile gcc does not proof that the compiler works. From my tests
with lang/gcc44 I get the impression that nobody did make test lately.
Many of the C99 tests fail due to a runtime warning which is rather
harmless, but that is the same problem which made lapack tests fail
due to a runtime warning about cabs/cabfs.
We have a fundamental problem here: wip/gcc45 started as a 1:1 copy
of lang/gcc44, but mabey it needs a different strategy similar to
FreeBSD: Handle all platform dependencies as far as possible
by using the binutil ld and as, dealing with platform problems in
devel/binutils. Always use the latest gcc snapshots and push all
bug fixes into gcc instead of pkgsrc. Patches would only be present
in the pkgsrc releases, not in pkgsrc-current. It is easier on FreeBSD
because it is a primary gcc platform and gcc gets regular test results
by an active community. I hate to admit it, but gcc users on NetBSD
including me did not give enough feedback to gcc to make this work.
We are in a lucky position with gfortran, because most fixes on FreeBSD
also worked on NetBSD and Steve Kargl works on gfortran and FreeBSD.
This does not work all the time. But if it works on FreeBSD there is
a good chance to adapt their solution to NetBSD. This porting of FreeBSD
code might be the key to success for other languages in gcc as well.

Pkgsrc has to handle platform dependencies between different operating
systems, versions and 30 different NetBSD ports. This needs a better
strategy for gcc or this remains a package only usable on some platforms,
which would break the purpose of pkgsrc. Any ideas ?

Kai-Uwe Eckhardt


-- 
-- 



------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
pkgsrc-wip-review mailing list
pkgsrc-wip-review%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review