headers
Chavdar Ivanov | 8 Aug 2011 01:37
Picon

Re: HEADS UP: port i386 and amd64 switched to GCC 4.5.3

On 7 August 2011 09:32, matthew green <mrg <at> eterna.com.au> wrote:
>
> hi folks.
>
>
> i've switched i386 and amd64 to use GCC 4.5.3 by default.  there
> shouldn't be any major issues, however update builds won't work.
> i recommend removing both destdir and objdir before rebuilding.
>
> if you need to revert this change, use build.sh -V HAVE_GCC=4.
>
> let me know if there are problems!  thanks.

Nice; no problems so far as far as I can see:

[uksup2] ~ $ /usr/bin/gcc --version
gcc (NetBSD nb1 20110620) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[uksup2] ~ $ uname -a
NetBSD uksup2 5.99.55 NetBSD 5.99.55 (GENERIC) #0: Sun Aug  7 15:18:14
BST 2011  root <at> uksup2:/usr/obj/usr-current/i386/sys/arch/i386/compile/GENERIC
i386

I didn't even notice it...

>
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hubert Feyrer | 8 Aug 2011 01:44
Picon
Favicon

Re: HEADS UP: port i386 and amd64 switched to GCC 4.5.3


>> let me know if there are problems!  thanks.

Cross-building from OS X, I get:

#   compile  ramdisk-g4u/getcap.o
/Users/feyrer/work/NetBSD/cvs/src-g4u/obj.i386/tooldir/bin/i486--netbsdelf-gcc 
-Os -std=gnu99 -Werror 
--sysroot=/Users/feyrer/work/NetBSD/cvs/src-g4u/obj.i386/destdir  -DSMALL 
-c

/Users/feyrer/work/NetBSD/cvs/src-g4u/distrib/utils/libhack/../../../lib/libc/gen/getcap.c
/Users/feyrer/work/NetBSD/cvs/src-g4u/distrib/utils/libhack/../../../lib/libc/gen/getcap.c:1213:1: 
internal compiler error: in execute_ipa_pass_list, at passes.c:1800
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://www.NetBSD.org/Misc/send-pr.html> for instructions.

*** Failed target:  getcap.o
*** Failed command: 
/Users/feyrer/work/NetBSD/cvs/src-g4u/obj.i386/tooldir/bin/i486--netbsdelf-gcc 
-Os -std=gnu99 -Werror 
--sysroot=/Users/feyrer/work/NetBSD/cvs/src-g4u/obj.i386/destdir -DSMALL 
-c 
/Users/feyrer/work/NetBSD/cvs/src-g4u/distrib/utils/libhack/../../../lib/libc/gen/getcap.c
*** Error code 1

  - Hubert
Permalink | Reply | 2 comments |
headers
Cherry G. Mathew | 10 Aug 2011 08:35
Picon

Re: merging bits of [cherry-xenmp]

>>>>> "Cherry" == Cherry G Mathew <cherry <at> zyx.in> writes:

>>>>> "haad" == haad  <haaaad <at> gmail.com> writes:
    haad> Hi,
    haad> On Sun, Aug 7, 2011 at 4:56 PM, Cherry G. Mathew <cherry <at> zyx.in> wrote:
    >>> Hi,
    >>> 
    >>> I'd like to start merging in bits of the cherry-xenmp branch
    >>> into -current over the coming week. The changes should be
    >>> transparent, and shouldn't change any behaviour of
    >>> -current. These include a few cleanups of MD code and some MP
    >>> related changes (eg: to x86 pmap)  that should be agnostic to
    >>> XEN UP, port-i386 and port-amd64. Where relevant, I will make
    >>> sure that code is reviewed before committing.

    haad> Can you share a diff with us ?

    Cherry> Here's a sample:
    Cherry> ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/port-xen/breakout1/earlyglue1.diff

Committed.
--

-- 
Cherry
Permalink | Reply | 0 comments |
headers
Alan Barrett | 16 Aug 2011 23:12
Gravatar

Re: removing boot ROMS

On Tue, 16 Aug 2011, John Nemeth wrote:
>     Right now on i386 and amd64, we create the following boot ROMS
>images: [snip]

>     I would like to remove them, since they are of little use 
> in modern systems.  The primary motivation for removing them 
> now is because I am running into size issues while creating 
> enhancements to /boot which shares code with these.

Ideally, these roms should be able to load a /boot program via 
dhcp/tftp/etc, much like a modern BIOS is able to do, and the 
/boot program could be almost arbitrarily large.  There's no real 
need for the roms to be able to boot netbsd directly, and so 
no need for the rom images to become larger when /boot becomes 
larger.

If that's not easily fixed, then I have no obection to removing 
them.

--apb (Alan Barrett)
Permalink | Reply | 2 comments |
headers
Martin Husemann | 17 Aug 2011 09:27
Picon

Re: removing boot ROMS

On Tue, Aug 16, 2011 at 11:12:50PM +0200, Alan Barrett wrote:
> If that's not easily fixed, then I have no obection to removing 
> them.

Ideally we could make them provide a PXE environment and chain to pxeboot -
but I have no idea how much work that would be.

Martin
Permalink | Reply | 1 comment |
headers
Martin Husemann | 17 Aug 2011 09:29
Picon

Re: removing boot ROMS

On Wed, Aug 17, 2011 at 09:27:18AM +0200, Martin Husemann wrote:
> Ideally we could make them provide a PXE environment and chain to pxeboot -
> but I have no idea how much work that would be.

Oh, and of course: that would require someone to have working cards and a
machine to test them in (which could be challenging for the ISA-only
variants) - and still leaves the question open if anyone would use
such a solution.

If not, removing them sounds like a good idea to me.

Martin
Permalink | Reply | 0 comments |

Gmane