pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fortran support - Re: pkgsrc-2013Q1 NetBSD 6.0/i386 2013-05-17 10:47



Thomas Klausner <wiz%NetBSD.org@localhost> writes:

> On Sun, May 19, 2013 at 12:14:25AM +0400, Aleksej Saushev wrote:
>>   Hello,
>> 
>> Just in case anyone wonders what the problem with post-1977 Fortran is,
>> here is the explanation:
>> 
>> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
>> 
>> > pkgsrc bulk build report
>> > ========================
>> >
>> > NetBSD 6.0/i386
>> > Compiler: gcc
>> >
>> > Build start: 2013-05-17 10:47
>> > Build end:   2013-05-17 20:50
>> >
>> > lang/gcc44                                   sbd%NetBSD.org@localhost
>> > lang/gcc45                                   sbd%NetBSD.org@localhost
>> > lang/gcc46                                   sbd%NetBSD.org@localhost
>> > lang/gcc47                                 2 sbd%NetBSD.org@localhost
>> 
>> We don't have _any_ reliably building modern compiler on NetBSD currently.
>
> Well, the base system contains one:
> "gcc (NetBSD nb2 20110806) 4.5.3"

GCC 4.5 is not enough, actually. 4.6 is the least acceptable version,
if we're talking about Fortran dialect in current use.

> The gcc47 package fails with
> /usr/include/x86/lock.h: Assembler messages:
> /usr/include/x86/lock.h:108: Error: bad register name `%sil'

I have to point out that GCC 4.7 didn't build for me on 6.1 RCn
for different reason until pkgsrcCon when it built the first time at all.
I had problems building pkgsrc GCC 4.7 on Debian/Ubuntu systems after
that time.

> This is described in PR 45673 and fixed in -current, and has been
> pulled up to 6.0.2 and 6.1, so this is basically fixed at least for
> current and 6.x.

Then this is the same old problem with official bulk builds.
NetBSD 6.0 builds should be thrown away in favour of 6.1 or 6.0.2 at least
until we get enough power to support it.

My point is that if we're going to solve problems around Fortran
by forcing everyone to use modern dialect, we should solve underlying
problems first. Currently, there's a lot of packages that rely on F77
directly or indirectly. When combined with our insistance on using
libtool it causes a lot of breakage. I don't know how to deal with it,
since most reasons lie in social problems:
 - NetBSD developers resist shipping Fortran compiler;
 - NetBSD developers resist building packages on reasonably new releases
   that contain necessary bug fixes;
 - pkgsrc developers insist on using libtool;
 - pkgsrc developers insist on using only post-77 Fortran with libtool
   (ignoring those very reasons why the split between "fortran" and
   "fortran77" was introduced).


-- 
BECHA...
   CKOPO CE3OH...



Home | Main Index | Thread Index | Old Index