From ardelean at ww.uni-erlangen.de Fri Aug 1 00:31:11 2008 From: ardelean at ww.uni-erlangen.de (Gheorghe Ardelean) Date: Fri Aug 1 00:31:18 2008 Subject: future for FBSD on alpha In-Reply-To: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> Message-ID: Hi, On Thu, 31 Jul 2008, Anton Shterenlikht wrote: > I wonder how many people run FBSD on alpha. > According to bsdstats.org very few - less than 5 boxes. > There must be more. Yes, there are more. I have 5 running 6.3 Release (AlphaPC64, AlphaPC164, 2x AXPpci33 w/custom kernel, PWS 433au). > I'm trying to find out if there are people on this list, who, > like myself, are keen to see FBSD supported on alpha > for say 1-3 more years. If yes, we might be able to lobby > ports maintainers not to drop support for alpha ports. Having us testing will help the port maintainers a lot. Best regards, Gheorghe Ardelean. From floort at gmail.com Fri Aug 1 00:48:42 2008 From: floort at gmail.com (Floor Terra) Date: Fri Aug 1 00:48:48 2008 Subject: future for FBSD on alpha In-Reply-To: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> Message-ID: On Thu, 31 Jul 2008, Anton Shterenlikht wrote: > I wonder how many people run FBSD on alpha. > According to bsdstats.org very few - less than 5 boxes. > There must be more. > I run FreeBSD on an Alpha. But because of the power requirements of keeping the machine running, its rarely powered on. So you can count me as an inactive user. It would be a shame to see an architecture dropped from support though.... > Is there a way to find out how many people are on this list? > Is it a good indicator? > > I, for one, am very keen to have some level of support > for FBSD on alpha, even at 6-stable branch. However, > if the actual usage is indeed very small, it must be expected > that ports maintainers will stop supporting alpha soon. > > I'm trying to find out if there are people on this list, who, > like myself, are keen to see FBSD supported on alpha > for say 1-3 more years. If yes, we might be able to lobby > ports maintainers not to drop support for alpha ports. > > I'm thinking at the moment about gcc42, firefox3, lapack, lapack95, > blas. > > many thanks > anton > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 928 8233 > Fax: +44 (0)117 929 4423 > _______________________________________________ > freebsd-alpha@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-alpha > To unsubscribe, send any mail to "freebsd-alpha-unsubscribe@freebsd.org" > -- Floor Terra www: http://brobding.mine.nu/ Netiquette Guidelines: http://www.apps.ietf.org/rfc/rfc1855.html From freebsd at sopwith.solgatos.com Fri Aug 1 06:08:17 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 1 06:08:24 2008 Subject: future for FBSD on alpha In-Reply-To: Your message of "Thu, 31 Jul 2008 23:10:15 BST." <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> Message-ID: <200808010530.FAA22725@sopwith.solgatos.com> > I wonder how many people run FBSD on alpha. > According to bsdstats.org very few - less than 5 boxes. > There must be more. There are lots of BSD machines that bsdstats.org doesn't know about. > Is there a way to find out how many people are on this list? > Is it a good indicator? Probably the best indicator I can think of. Some people on the list will be running multiple machines, others will be just reading the list but not running any machines. For example, I'm running NetBSD on my Alphas. > I'm trying to find out if there are people on this list, who, > like myself, are keen to see FBSD supported on alpha > for say 1-3 more years. If yes, we might be able to lobby > ports maintainers not to drop support for alpha ports. I might be interested in switching from Net to Free, but if support is going away that would be a bad idea. 1-3 years isn't very long. This is part of a larger problem. NetBSD is also dropping support for arches. People don't want to support things like uucp or usenet any more. Anything more than 5 nanoseconds old just isn't considered cool. Even if the replacements are far worse, which is often the case. What are we supposed to do with older boxes? Some applications that don't require the latest fast hardware, like firewalls, still require support and security fixes. Throwing machines into the landfill isn't very green. Sometimes a developer will complain that maintaining support for something takes too much time, but will then spend large amounts of time removing support. Hmmmmm... From mexas at bristol.ac.uk Fri Aug 1 08:55:35 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 08:55:42 2008 Subject: firefox3 build fails on alpha In-Reply-To: References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080708122352.GA76546@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> On Thu, Jul 31, 2008 at 05:42:17PM -0500, Jeremy Messenger wrote: > On Thu, 31 Jul 2008 17:24:43 -0500, Anton Shterenlikht > wrote: > > > On Sun, Jul 13, 2008 at 12:59:29AM +0200, Wilko Bulte wrote: > >> Quoting Jeremy Messenger, who wrote on Sat, Jul 12, 2008 at 05:44:11PM > >> -0500 .. > >> > On Tue, 08 Jul 2008 07:23:52 -0500, Anton Shterenlikht > >> > wrote: > >> > > > >> > > A followup. It seems xptcinvoke_freebsd_alpha.cpp is missing. It > >> > > is used in Makefile: > >> > > >> > I think most of us don't have any alpha machine. You might have to > >> create > >> > patch for us. I think, the alpha support has been dropped so it's > >> > pointless for us to work on alpha support. > >> > >> The latest release of FreeBSD supporting the Alpha platform port is > >> RELENG_6. Anything newer no longer supports Alpha. > > > > I'm happy with RELENG_6 on alpha. > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > In this particular case it seems that (at least) 2 files > > are missing from the distribution: > > > > xptcinvoke_freebsd_alpha.cpp > > xptcstubs_freebsd_alpha.cpp > > > > (curiously the corresponding *alpha.cpp files are present for osf1, > > linux, > > openvms and openbsd). > > > > I think that whoever created the tar file simply forgot to add the > > freebsd > > files. > > > > I did try to contact mozilla developers directly, but no reply so far. > > I understand that mozilla developers put out the tar file. Perhaps the > > port maintainers could alert the mozilla team about the missing files, > > or maybe even get these 2 files. I'd be very greatful. > > Have you tried 3.0.1 yet? The Makefile.in has changed by Mozilla team: > > --------------------------------------------------- > ###################################################################### > # > # Tru64/Alpha > # > ifeq ($(OS_ARCH)$(OS_TEST),OSF1alpha) > CPPSRCS := xptcinvoke_osf1_alpha.cpp xptcstubs_osf1_alpha.cpp > ASFILES := xptcinvoke_asm_osf1_alpha.s xptcstubs_asm_osf1_alpha.s > endif > # > # Linux/Alpha > # > ifneq (,$(filter Linuxalpha FreeBSDalpha NetBSDalpha,$(OS_ARCH)$(OS_TEST))) > CPPSRCS := xptcinvoke_linux_alpha.cpp xptcstubs_linux_alpha.cpp > endif > --------------------------------------------------- > > But I have no idea if it works. I just tried again, and get the same error: gmake[8]: Entering directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect /xptcall/src/md/unix' gmake[8]: *** No rule to make target `xptcinvoke_freebsd_alpha.o', needed by `li bxptcmd.a'. Stop. gmake[8]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/ xptcall/src/md/unix' gmake[7]: *** [libs] Error 2 Also my Makefile.in under /usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md/unix still requires these 2 files: ###################################################################### # Alpha ###################################################################### # [skip] # # FreeBSD/Alpha # ifeq ($(OS_ARCH)$(OS_TEST),FreeBSDalpha) CPPSRCS := xptcinvoke_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp endif which are missing: -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Aug 1 09:10:21 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 09:10:30 2008 Subject: anybody running port www/amaya Message-ID: <20080801091015.GA92710@mech-cluster238.men.bris.ac.uk> Being unable to build firefox3 on alpha I turned in desperation to other web browsers from ports. I built www/amaya fine, but get this error on start-up: % amaya Gdk-ERROR **: BadValue (integer parameter out of range for operation) serial 129 error_code 2 request_code 51 minor_code 0 % The developers' advice is to use devel/strace to trace the problem, but it only builds on i386. Is anybody using this port on alpha? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From macgyver at calibre-solutions.co.uk Fri Aug 1 09:49:37 2008 From: macgyver at calibre-solutions.co.uk (Angus MacGyver) Date: Fri Aug 1 09:49:45 2008 Subject: future for FBSD on alpha In-Reply-To: References: Message-ID: On Fri, August 1, 2008 00:06, Gheorghe Ardelean wrote: > > Hi, > > On Thu, 31 Jul 2008, Anton Shterenlikht wrote: > >> I wonder how many people run FBSD on alpha. >> According to bsdstats.org very few - less than 5 boxes. >> There must be more. > > Yes, there are more. I have 5 running 6.3 Release (AlphaPC64, AlphaPC164, > 2x AXPpci33 w/custom kernel, PWS 433au). Indeed more - I counted 15 on there (remembering to look at all possible flavours - Digital etc) FBSD on AXP architecture has been the most stable, bombproof system I have ever run. (always custom kernel, and upto 4 Jails per physical machine) It is a great shame that Compaq and HP mis-managed this architecture to the point of obselesence - totally criminal IMHO. >> I'm trying to find out if there are people on this list, who, >> like myself, are keen to see FBSD supported on alpha >> for say 1-3 more years. If yes, we might be able to lobby >> ports maintainers not to drop support for alpha ports. If FBSD hasn't announced EOL - then I would still be running it on AXP - at least until the hardware gave out (and I had 5 machines as well - 2x LX164 and 3x SX164 - so that could have been quite some time) As it was - I (only just) migrated to x86 kit (at least it's low power!) to make sure my production kit wasn't adversely affected by quality or security issues when the ports started to falter. > > Having us testing will help the port maintainers a lot. Whilst I would support testing - I personally have fairly limited time to build and test now - and quite a lot of sysadmins I know are in the same boat. If there are enough people to do this - then it might just work. The we must do - if this is going to go ahead, - is to make reasonable decisions about what ports are the "most wanted" - say apache22 and mysql for example - and not "care" about something like "joe" (I just use these as examples - after all one can use a different editor - but a different webserver or DB is another matter) just my $0.02 > Best regards, AM From mexas at bristol.ac.uk Fri Aug 1 11:06:19 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 11:06:26 2008 Subject: future for FBSD on alpha In-Reply-To: References: Message-ID: <20080801110614.GA17503@mech-cluster238.men.bris.ac.uk> On Fri, Aug 01, 2008 at 09:34:25AM -0000, Angus MacGyver wrote: > > On Fri, August 1, 2008 00:06, Gheorghe Ardelean wrote: > > > > Having us testing will help the port maintainers a lot. > > > Whilst I would support testing - I personally have fairly limited time to > build and test now - and quite a lot of sysadmins I know are in the same > boat. > > If there are enough people to do this - then it might just work. > > The we must do - if this is going to go ahead, - is to make reasonable > decisions about what ports are the "most wanted" - say apache22 and mysql > for example - and not "care" about something like "joe" (I just use these > as examples - after all one can use a different editor - but a different > webserver or DB is another matter) this sounds like a good idea - a list of most wanted ports. However, even 1 or 2 big ports might require lots of dependencies. For example I've 229 ports at present, of which only 20 or so are top level, like ImageMagick, xpdf, teTeX, some X clients. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Aug 1 11:35:49 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 11:35:55 2008 Subject: future for FBSD on alpha In-Reply-To: <200808010530.FAA22725@sopwith.solgatos.com> References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> <200808010530.FAA22725@sopwith.solgatos.com> Message-ID: <20080801113541.GA24809@mech-cluster238.men.bris.ac.uk> On Thu, Jul 31, 2008 at 10:30:01PM +0100, Dieter wrote: > > I wonder how many people run FBSD on alpha. > > According to bsdstats.org very few - less than 5 boxes. > > There must be more. > > There are lots of BSD machines that bsdstats.org doesn't > know about. > > > Is there a way to find out how many people are on this list? > > Is it a good indicator? > > Probably the best indicator I can think of. So how to find out the list membership? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Aug 1 11:51:26 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 11:51:37 2008 Subject: firefox3 build fails on alpha In-Reply-To: <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080708122352.GA76546@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801115109.GA25235@mech-cluster238.men.bris.ac.uk> On Fri, Aug 01, 2008 at 09:55:27AM +0100, Anton Shterenlikht wrote: > On Thu, Jul 31, 2008 at 05:42:17PM -0500, Jeremy Messenger wrote: > > On Thu, 31 Jul 2008 17:24:43 -0500, Anton Shterenlikht > > wrote: > > > > > On Sun, Jul 13, 2008 at 12:59:29AM +0200, Wilko Bulte wrote: > > >> Quoting Jeremy Messenger, who wrote on Sat, Jul 12, 2008 at 05:44:11PM > > >> -0500 .. > > >> > On Tue, 08 Jul 2008 07:23:52 -0500, Anton Shterenlikht > > >> > wrote: > > >> > > > > >> > > A followup. It seems xptcinvoke_freebsd_alpha.cpp is missing. It > > >> > > is used in Makefile: > > >> > > > >> > I think most of us don't have any alpha machine. You might have to > > >> create > > >> > patch for us. I think, the alpha support has been dropped so it's > > >> > pointless for us to work on alpha support. > > >> > > >> The latest release of FreeBSD supporting the Alpha platform port is > > >> RELENG_6. Anything newer no longer supports Alpha. > > > > > > I'm happy with RELENG_6 on alpha. > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > In this particular case it seems that (at least) 2 files > > > are missing from the distribution: > > > > > > xptcinvoke_freebsd_alpha.cpp > > > xptcstubs_freebsd_alpha.cpp > > > > > > (curiously the corresponding *alpha.cpp files are present for osf1, > > > linux, > > > openvms and openbsd). > > > > > > I think that whoever created the tar file simply forgot to add the > > > freebsd > > > files. > > > > > > I did try to contact mozilla developers directly, but no reply so far. > > > I understand that mozilla developers put out the tar file. Perhaps the > > > port maintainers could alert the mozilla team about the missing files, > > > or maybe even get these 2 files. I'd be very greatful. > > > > Have you tried 3.0.1 yet? The Makefile.in has changed by Mozilla team: > > > > --------------------------------------------------- > > ###################################################################### > > # > > # Tru64/Alpha > > # > > ifeq ($(OS_ARCH)$(OS_TEST),OSF1alpha) > > CPPSRCS := xptcinvoke_osf1_alpha.cpp xptcstubs_osf1_alpha.cpp > > ASFILES := xptcinvoke_asm_osf1_alpha.s xptcstubs_asm_osf1_alpha.s > > endif > > # > > # Linux/Alpha > > # > > ifneq (,$(filter Linuxalpha FreeBSDalpha NetBSDalpha,$(OS_ARCH)$(OS_TEST))) > > CPPSRCS := xptcinvoke_linux_alpha.cpp xptcstubs_linux_alpha.cpp > > endif > > --------------------------------------------------- > > > > But I have no idea if it works. > > I just tried again, and get the same error: > > gmake[8]: Entering directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect > /xptcall/src/md/unix' > gmake[8]: *** No rule to make target `xptcinvoke_freebsd_alpha.o', needed by `li > bxptcmd.a'. Stop. > gmake[8]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/ > xptcall/src/md/unix' > gmake[7]: *** [libs] Error 2 > > Also my Makefile.in under > /usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md/unix > > still requires these 2 files. I tried to copy these 2 files from firefox to firefox3. One file compiles, the other does not: gmake[8]: Entering directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect /xptcall/src/md/unix' xptcinvoke_freebsd_alpha.cpp c++ -o xptcinvoke_freebsd_alpha.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD6 \" -DOSARCH=FreeBSD -DEXPORT_XPTC_API -D_IMPL_NS_COM -I./../.. -I./../../../../x ptinfo/src -I. -I. -I../../../../../../dist/include/string -I../../../../../../ dist/include -I../../../../../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/loc al/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverlo aded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align - Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-ali asing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -I/usr/local/include -I/usr/l ocal/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h xptcin voke_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp c++ -o xptcstubs_freebsd_alpha.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD6\ " -DOSARCH=FreeBSD -DEXPORT_XPTC_API -D_IMPL_NS_COM -I./../.. -I./../../../../xp tinfo/src -I. -I. -I../../../../../../dist/include/string -I../../../../../../d ist/include -I../../../../../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/loca l/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloa ded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -W no-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-alia sing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -I/usr/local/include -I/usr/lo cal/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h xptcstu bs_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp: In function `nsresult PrepareAndDispatch(nsXPTCStub Base*, uint32, PRUint64*)': xptcstubs_freebsd_alpha.cpp:59: error: `nsIInterfaceInfo' was not declared in th is scope xptcstubs_freebsd_alpha.cpp:59: error: `iface_info' was not declared in this sco pe xptcstubs_freebsd_alpha.cpp:67: error: 'class nsXPTCStubBase' has no member name d 'GetInterfaceInfo' xptcstubs_freebsd_alpha.cpp:131: error: 'class nsXPTCStubBase' has no member nam ed 'CallMethod' xptcstubs_freebsd_alpha.cpp:59: warning: unused variable 'nsIInterfaceInfo' gmake[8]: *** [xptcstubs_freebsd_alpha.o] Error 1 gmake[8]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/ xptcall/src/md/unix' gmake[7]: *** [libs] Error 2 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From ardelean at ww.uni-erlangen.de Fri Aug 1 12:03:42 2008 From: ardelean at ww.uni-erlangen.de (Gheorghe Ardelean) Date: Fri Aug 1 12:03:49 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801110614.GA17503@mech-cluster238.men.bris.ac.uk> Message-ID: On Fri, 1 Aug 2008, Anton Shterenlikht wrote: > On Fri, Aug 01, 2008 at 09:34:25AM -0000, Angus MacGyver wrote: > > > > On Fri, August 1, 2008 00:06, Gheorghe Ardelean wrote: > > > > > > Having us testing will help the port maintainers a lot. > > > > > > Whilst I would support testing - I personally have fairly limited time to > > build and test now - and quite a lot of sysadmins I know are in the same > > boat. > > > > If there are enough people to do this - then it might just work. > > > > The we must do - if this is going to go ahead, - is to make reasonable > > decisions about what ports are the "most wanted" - say apache22 and mysql > > for example - and not "care" about something like "joe" (I just use these > > as examples - after all one can use a different editor - but a different > > webserver or DB is another matter) > > this sounds like a good idea - a list of most wanted ports. > However, even 1 or 2 big ports might require lots of dependencies. > For example I've 229 ports at present, of which only 20 or so > are top level, like ImageMagick, xpdf, teTeX, some X clients. I am also planing to upload the ports I have built during my 6.3-Release testing on my alphas. My plans are to upload to ftp.ro.freebsd.org (the server I manage) but I do not know in wich directory. Maybe packages-6.3-release-local or so ?! Wilko would this be ok? What about smoething similar to this: http://wiki.freebsd.org/FreeBSD/sparc64/Volunteers Best regards, Gheorghe Ardelean. From mexas at bristol.ac.uk Fri Aug 1 12:04:48 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 12:04:53 2008 Subject: future for FBSD on alpha In-Reply-To: <54163.68650.qm@web32708.mail.mud.yahoo.com> References: <54163.68650.qm@web32708.mail.mud.yahoo.com> Message-ID: <20080801120440.GA29656@mech-cluster238.men.bris.ac.uk> On Thu, Jul 31, 2008 at 09:08:43PM -0700, Pedro Giffuni wrote: > > Hmm.. also.. since you are in the Mechanical Engineering dept., you'll be glad to know that Code Aster is developed in alpha machines. > Why is it under ports/french? Shouldn't it be under math or science? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Fri Aug 1 14:38:33 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 14:38:44 2008 Subject: firefox2 works fine [WAS: Re: firefox3 build fails on alpha] In-Reply-To: <20080801115109.GA25235@mech-cluster238.men.bris.ac.uk> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080708122352.GA76546@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> <20080801115109.GA25235@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801143828.GC34016@mech-cluster238.men.bris.ac.uk> Anybody else running firefox2 on alpha? Anybody else interested in firefox3? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From ardelean at ww.uni-erlangen.de Fri Aug 1 14:45:52 2008 From: ardelean at ww.uni-erlangen.de (Gheorghe Ardelean) Date: Fri Aug 1 14:46:02 2008 Subject: firefox2 works fine [WAS: Re: firefox3 build fails on alpha] In-Reply-To: <20080801143828.GC34016@mech-cluster238.men.bris.ac.uk> Message-ID: On Fri, 1 Aug 2008, Anton Shterenlikht wrote: > Anybody else running firefox2 on alpha? Yes! I do. Regards, Gheorghe Ardelean From pfgshield-freebsd at yahoo.com Fri Aug 1 14:56:23 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Fri Aug 1 14:56:29 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801120440.GA29656@mech-cluster238.men.bris.ac.uk> Message-ID: <300257.17954.qm@web32707.mail.mud.yahoo.com> --- Ven 1/8/08, Anton Shterenlikht ha scritto: > Da: Anton Shterenlikht > > > > Hmm.. also.. since you are in the Mechanical > Engineering dept., you'll be glad to know that Code > Aster is developed in alpha machines. > > > > Why is it under ports/french? Code Aster was developed by EDF, so the original (and complete) documentation is available in French. > Shouldn't it be under math or science? > It is also listed in CAD. Pedro. Posta, news, sport, oroscopo: tutto in una sola pagina. Crea l'home page che piace a te! www.yahoo.it/latuapagina From wb at freebie.xs4all.nl Fri Aug 1 14:58:34 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Fri Aug 1 14:58:41 2008 Subject: firefox3 build fails on alpha In-Reply-To: <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080708122352.GA76546@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801145822.GC1356@freebie.xs4all.nl> Quoting Anton Shterenlikht, who wrote on Thu, Jul 31, 2008 at 11:24:43PM +0100 .. > On Sun, Jul 13, 2008 at 12:59:29AM +0200, Wilko Bulte wrote: > > Quoting Jeremy Messenger, who wrote on Sat, Jul 12, 2008 at 05:44:11PM -0500 .. > > > On Tue, 08 Jul 2008 07:23:52 -0500, Anton Shterenlikht > > > wrote: > > > > > > > > A followup. It seems xptcinvoke_freebsd_alpha.cpp is missing. It > > > > is used in Makefile: > > > > > > I think most of us don't have any alpha machine. You might have to create > > > patch for us. I think, the alpha support has been dropped so it's > > > pointless for us to work on alpha support. > > > > The latest release of FreeBSD supporting the Alpha platform port is > > RELENG_6. Anything newer no longer supports Alpha. > > I'm happy with RELENG_6 on alpha. Nice to hear that. Thing is, ports have not been built on -alpha for ages now. There is not even a working Alpha machine anymore in the FreeBSD.org cluster for ports folks to test on if they were inclined to do so. ports have always been tricky on alpha, given the limited # of people running FreeBSD on Alpha. With the Alpha port effectively dead, and the amount of work of the ports committers going into current releases and archs I do not have high hopes. > I did try to contact mozilla developers directly, but no reply so far. > I understand that mozilla developers put out the tar file. Perhaps the > port maintainers could alert the mozilla team about the missing files, > or maybe even get these 2 files. I'd be very greatful. ENOCLUE on this one. -- Wilko Bulte wilko@FreeBSD.org From wb at freebie.xs4all.nl Fri Aug 1 15:08:36 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Fri Aug 1 15:08:45 2008 Subject: future for FBSD on alpha In-Reply-To: <200808010530.FAA22725@sopwith.solgatos.com> References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> <200808010530.FAA22725@sopwith.solgatos.com> Message-ID: <20080801150833.GE1356@freebie.xs4all.nl> Quoting Dieter, who wrote on Thu, Jul 31, 2008 at 10:30:01PM +0100 .. > > I wonder how many people run FBSD on alpha. > > According to bsdstats.org very few - less than 5 boxes. > > There must be more. > > There are lots of BSD machines that bsdstats.org doesn't > know about. Indeed. > > like myself, are keen to see FBSD supported on alpha > > for say 1-3 more years. If yes, we might be able to lobby > > ports maintainers not to drop support for alpha ports. > > I might be interested in switching from Net to Free, but if > support is going away that would be a bad idea. 1-3 years In all reality FreeBSD on Alpha is with one foot in the grave. After FreeBSD-6.x goes EOL things are dead. It would have been better (read: it would have made survivability of the Alpha-port a lot better) if people had voiced their interest/support a bit earlier.. Regardless, it is water under the bridge now. > isn't very long. This is part of a larger problem. NetBSD > is also dropping support for arches. People don't want to > support things like uucp or usenet any more. Anything more > than 5 nanoseconds old just isn't considered cool. Even if > the replacements are far worse, which is often the case. > What are we supposed to do with older boxes? Some applications > that don't require the latest fast hardware, like firewalls, > still require support and security fixes. Throwing machines > into the landfill isn't very green. True. On the other hand, the power consumption of the average / current Alpha is not exactly green either. I am not running mine regularly, only when I build releases/snapshots. -- Wilko Bulte wilko@FreeBSD.org From mexas at bristol.ac.uk Fri Aug 1 15:36:03 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 15:36:10 2008 Subject: future for FBSD on alpha In-Reply-To: <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECAD0@depot.AxxisCorp.local> References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECACD@depot.AxxisCorp.local> <20080731223325.GA35980@mech-cluster238.men.bris.ac.uk> <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECAD0@depot.AxxisCorp.local> Message-ID: <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> On Fri, Aug 01, 2008 at 10:20:51AM -0500, Richard J. Valenta wrote: > I am not familiar with bsdstats at all... basically if you install port sysutils/bsdstats (just a shell script), it will send a message from your box monthly to to bsdstats.org with arch, os version, etc. The idea is to lobby software producers into supporting their stuff on bsd by showing a large number of live bsd systems. My interest is in lobbying fbsd management team not to drop alpha support by showing a large number of live fbsd alpha systems. At present the numbers are so low that even RELENG_6 support might stop soon. If more people participated and a more realistic (read higher) number of alpha boxes appeared, perhaps we could prolong the life of fbsd on alpha. However, I agree with Wilko, fbsd on alpha is half dead. anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From wb at freebie.xs4all.nl Fri Aug 1 15:50:59 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Fri Aug 1 15:51:06 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECACD@depot.AxxisCorp.local> <20080731223325.GA35980@mech-cluster238.men.bris.ac.uk> <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECAD0@depot.AxxisCorp.local> <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801155042.GA1817@freebie.xs4all.nl> Quoting Anton Shterenlikht, who wrote on Fri, Aug 01, 2008 at 04:35:56PM +0100 .. > On Fri, Aug 01, 2008 at 10:20:51AM -0500, Richard J. Valenta wrote: > > I am not familiar with bsdstats at all... > > basically if you install port sysutils/bsdstats (just a shell script), > it will send a message from your box monthly to to bsdstats.org > with arch, os version, etc. The idea is to lobby software > producers into supporting their stuff on bsd by showing a large number > of live bsd systems. > > My interest is in lobbying fbsd management team not to drop alpha > support by showing a large number of live fbsd alpha systems. At present Guys.. there is no such thing as a management team that can force committers on Alpha. Or anything subject in FreeBSD for that matter. Please remember that FreeBSD is a volunteer driven project. > the numbers are so low that even RELENG_6 support might stop soon. Alpha support is gone from the cvs (well.. svn now) repository for anything newer than RELENG_6. If you follow the cvs/svn commit messages you will have seen that. > If more people participated and a more realistic (read higher) number > of alpha boxes appeared, perhaps we could prolong the life of fbsd on alpha. It is too late.. sorry but thats a fact of life. -- Wilko Bulte wilko@FreeBSD.org From freebsd at sopwith.solgatos.com Fri Aug 1 16:00:53 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 1 16:00:59 2008 Subject: web browsers for Alpha (was: Re: anybody running port www/amaya) In-Reply-To: Your message of "Fri, 01 Aug 2008 10:10:15 BST." <20080801091015.GA92710@mech-cluster238.men.bris.ac.uk> Message-ID: <200808011559.PAA01605@sopwith.solgatos.com> > Being unable to build firefox3 on alpha Have they done anything to make firefox LP64 clean? It's been awhile, but I once tried to get firefox to build on NetBSD/Alpha and got over 30,000 complaints from the compiler. Looking at the code, it was clear that the author thought all the world was ILP32. I submitted a patch fixing over 1100 problems but the firefox crew was very hostile, and I doubt they ever did anything with the patch. > I turned in desperation > to other web browsers from ports. Oddly Mozilla runs on both NetBSD/Alpha and FreeBSD/AMD64. I thought Firefox was just Mozilla with some non-web-browser stuff removed, but perhaps there are other differences. You might try Links and/or Dillo. Smaller, faster, higher quality code. They work on LP64 machines. Unfortunately they may not have all the features you need. Links (with -g for graphics mode) allows setting the font to any size you want, you can make it very small to get a poorly designed web page to fit on your screen, or crank it up if your eyes are tired. It also allows changing the size of images, which even mozilla-the-bloatfest can't do. Dillo actually cares about security. From macgyver at calibre-solutions.co.uk Fri Aug 1 16:13:11 2008 From: macgyver at calibre-solutions.co.uk (macgyver) Date: Fri Aug 1 16:13:22 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801110614.GA17503@mech-cluster238.men.bris.ac.uk> References: <20080801110614.GA17503@mech-cluster238.men.bris.ac.uk> Message-ID: <1217607190.8664.9.camel@executor> On Fri, 2008-08-01 at 12:06 +0100, Anton Shterenlikht wrote: > On Fri, Aug 01, 2008 at 09:34:25AM -0000, Angus MacGyver wrote: > > > > The we must do - if this is going to go ahead, - is to make reasonable > > decisions about what ports are the "most wanted" - say apache22 and mysql > > for example - and not "care" about something like "joe" (I just use these > > as examples - after all one can use a different editor - but a different > > webserver or DB is another matter) > > this sounds like a good idea - a list of most wanted ports. > However, even 1 or 2 big ports might require lots of dependencies. > For example I've 229 ports at present, of which only 20 or so > are top level, like ImageMagick, xpdf, teTeX, some X clients. > Big ports - yeah true - gotta start somewhere mind... I have 84 on this replacement x86 box - and it won't have been much different from the AXP machine - as it does pretty much same job. Another question that probably needs answering - and that may well skew what ports will be required - what do we all use AXP's for ? Me for example ran one as a webserver with no graphics card - just serial line access (the jails were each DNS/IRC/Mail/Http for isolation) I also ran another virtually identical (+gfx card) machine as a desktop (tell you what - I *knew* when I had that thing turned on - I didn't need to have the heating on upstairs!!!) Completely different uses will radically alter what ports are required. Regards AM From freebsd at sopwith.solgatos.com Fri Aug 1 16:22:05 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 1 16:22:10 2008 Subject: future for FBSD on alpha In-Reply-To: Your message of "Fri, 01 Aug 2008 09:34:25 -0000." Message-ID: <200808011616.QAA11263@sopwith.solgatos.com> > It is a great shame that Compaq and HP mis-managed this architecture to > the point of obselesence - totally criminal IMHO. The criminal part is that Inthell stole (yes stole) technology from DEC. DEC could have, and should have, shut Inthell down, but what's-his-name wimped out. One has to wonder what happened under the table. > As it was - I (only just) migrated to x86 kit (at least it's low power!) There's AMD64, with DEC technology that was obtained legally and morally. Although it is still a case of trying to make a silk purse (AMD64) from a sow's ear (x86). From mexas at bristol.ac.uk Fri Aug 1 16:24:33 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 16:24:40 2008 Subject: future for FBSD on alpha In-Reply-To: <1217607190.8664.9.camel@executor> References: <20080801110614.GA17503@mech-cluster238.men.bris.ac.uk> <1217607190.8664.9.camel@executor> Message-ID: <20080801162422.GA73400@mech-cluster238.men.bris.ac.uk> On Fri, Aug 01, 2008 at 05:13:10PM +0100, macgyver wrote: > On Fri, 2008-08-01 at 12:06 +0100, Anton Shterenlikht wrote: > > On Fri, Aug 01, 2008 at 09:34:25AM -0000, Angus MacGyver wrote: > > Me for example ran one as a webserver with no graphics card - just > serial line access (the jails were each DNS/IRC/Mail/Http for isolation) > > > I also ran another virtually identical (+gfx card) machine as a desktop > (tell you what - I *knew* when I had that thing turned on - I didn't > need to have the heating on upstairs!!!) > > Completely different uses will radically alter what ports are required. sure, and different energy concerns. I've several ds10l in an air-con server room far away. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From freebsd at sopwith.solgatos.com Fri Aug 1 17:00:52 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 1 17:01:03 2008 Subject: firefox3 build fails on alpha In-Reply-To: Your message of "Fri, 01 Aug 2008 16:58:22 +0200." <20080801145822.GC1356@freebie.xs4all.nl> Message-ID: <200808011653.QAA17051@sopwith.solgatos.com> > Thing is, ports have not been built on -alpha for > ages now. There is not even a working Alpha machine anymore in the > FreeBSD.org cluster for ports folks to test on if they were inclined to do > so. ports have always been tricky on alpha, given the limited # of people > running FreeBSD on Alpha. I've been running NetBSD/Alpha for many years, and beaten a lot of software into submission on it. I don't recall a single problem that wasn't ILP32 vs LP64. FreeBSD runs on AMD64, AMD64 is LP64, so what is the big problem getting apps to run on Alpha once they run on AMD64? Yes, I know that a lot of programs still aren't LP64 clean even today and therefore don't run properly on AMD64. But that isn't specific to Alpha. Turn the portability compiler warnings on (e.g. require function prototypes), fix the compiler warnings. At that point programs will run as well on AMD64 and Alpha as they do on x86. In theory there are 64 bit problems that compilers can't warn about, but I have never found any in code I've ported. When I compile ports on FreeBSD/AMD64 I usually see a bunch of compiler warnings fly by. Just because the compiler says warning rather than error doesn't mean you can ignore it. Warnings can and do point to actual bugs. Good quality code has NO compiler warnings. The only program I recall giving up on was firefox, and only because it was soooo big, sooo badly written, with soooo many problems, and so much hostility from the firefox people. Firefox in the original Greek means "segmentation fault". From macgyver at calibre-solutions.co.uk Fri Aug 1 17:02:29 2008 From: macgyver at calibre-solutions.co.uk (Angus MacGyver) Date: Fri Aug 1 17:02:36 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECACD@depot.AxxisCorp.local> <20080731223325.GA35980@mech-cluster238.men.bris.ac.uk> <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECAD0@depot.AxxisCorp.local> <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> Message-ID: <1217610147.8664.37.camel@executor> On Fri, 2008-08-01 at 16:35 +0100, Anton Shterenlikht wrote: On Fri, Aug 01, 2008 at 10:20:51AM -0500, Richard J. Valenta wrote: > I am not familiar with bsdstats at all... > My interest is in lobbying fbsd management team not to drop alpha > support by showing a large number of live fbsd alpha systems. At present > the numbers are so low that even RELENG_6 support might stop soon. > If more people participated and a more realistic (read higher) number > of alpha boxes appeared, perhaps we could prolong the life of fbsd on alpha. > However, I agree with Wilko, fbsd on alpha is half dead. > > anton > ? bsdstats - Neither was I. Not something that has exactly jumped out at me when installing at any point - unlike say other platforms (/methinks suse/ubuntu/fedora - let alone M$) Perhaps if that had been the case - more people would have known about it and participated and this situation may have bought the platform more time. - again as Wilko said - water under bridge :( /me fires up current BSD boxes to do just that - pity it's for a VIA C7 But as with anything open source - it never really dies - there is nothing to stop people interested enough, taking that code and continuing the work - should they choose to do so. (ignoring actually the part of doing it) Ditto with the vast majority of software that is run on the systems. Now - I'm not as familiar with the whole FBSD project "heirachy" or nooks and crannies of the BSD license - nor am I familiar enough about such issues as "forking" - but if pressure is enough - people do actually take on these sort of things. (I'm intentionally skipping if this would be a good idea etc. - I'm pointing out what is hard^H^H^H^H possible.) ?Let's face it - due to the age of the AXP platform - what else "new" would anyone want into the kernel for example ? Maybe better SMP - but I'd suggest that it's not like there is much else hardware wise that we would be putting into these machines is it ? That would/could remain fairly static. Security fixes is another matter however ...... I was going to mention alphacore - a Fedora Linux for Alpha - but then saw looked rather dead until i came across .. http://alphacore.info/forum/viewtopic.php?id=1785 OK- it ain't FBSD - but - might prolong those systems for a bit longer ??? again - my ~$0.04 (at today's exchange rate :-/ ) AM From mexas at bristol.ac.uk Fri Aug 1 17:18:06 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Fri Aug 1 17:18:35 2008 Subject: future for FBSD on alpha In-Reply-To: References: <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801171755.GA87554@mech-cluster238.men.bris.ac.uk> On Fri, Aug 01, 2008 at 11:06:15AM -0600, Richard Loken wrote: > On Fri, 1 Aug 2008, Anton Shterenlikht wrote: > > > basically if you install port sysutils/bsdstats (just a shell script), > > it will send a message from your box monthly to to bsdstats.org > > with arch, os version, etc. The idea is to lobby software > > producers into supporting their stuff on bsd by showing a large number > > of live bsd systems. > > It is shame that I (and maybe a few thousand other Alpha FreeBSD users) > hadn't heard of bsdstats and bsdstats.org five or more years ago. I find > it amazing that the open source OS's for Alphas are deemed dead befor HP > themselves have finished filling in the grave. I think it is still useful if people participate in bsdstats.org. If not for alpha, then for FBSD sake. It would be great if more commercial software was supported on FBSD (whatever architecture), and for this bigger numbers are required. > > Fruther to this non-communication/miscommunication morass, I have never > upgraded my PC164 beyond FreeBSD 5 because I was led to believe that X > did not work on Alpha version 6. Sheesh... It is my home workstation so > I want X on it and, yes, it does help to keep me warm in the winter. I run xdmcp and X clients on ds10l - I like it. I usually run servers on i386 FBSD-7 - no problems. > As for winning the heating and power consumption war. My work station here > in the office is an Alphaserver 4100 with two 600MHz CPU's and 4G of memory > running OpenVMS 7.3-1. I am used to the hum and it keeps the office warm. > > Why VMS? Because I was abandoned by FreeBSD. I also run a VMS 8.3 Alpha-I64 cluster under free educational licence. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From wb at freebie.xs4all.nl Fri Aug 1 17:54:34 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Fri Aug 1 17:54:40 2008 Subject: firefox3 build fails on alpha In-Reply-To: <200808011653.QAA17051@sopwith.solgatos.com> References: <20080801145822.GC1356@freebie.xs4all.nl> <200808011653.QAA17051@sopwith.solgatos.com> Message-ID: <20080801175430.GA2860@freebie.xs4all.nl> Quoting Dieter, who wrote on Fri, Aug 01, 2008 at 09:53:25AM +0100 .. > > Thing is, ports have not been built on -alpha for > > ages now. There is not even a working Alpha machine anymore in the > > FreeBSD.org cluster for ports folks to test on if they were inclined to do > > so. ports have always been tricky on alpha, given the limited # of people > > running FreeBSD on Alpha. > > I've been running NetBSD/Alpha for many years, and beaten a lot of software > into submission on it. I don't recall a single problem that wasn't ILP32 > vs LP64. FreeBSD runs on AMD64, AMD64 is LP64, so what is the big problem > getting apps to run on Alpha once they run on AMD64? Yes, I know that People willing to spend the time, do the work, test the work etc etc. > hostility from the firefox people. > > Firefox in the original Greek means "segmentation fault". ;-) -- Wilko Bulte wilko@FreeBSD.org From richardlo at admin.athabascau.ca Fri Aug 1 19:27:30 2008 From: richardlo at admin.athabascau.ca (Richard Loken) Date: Fri Aug 1 19:27:37 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> Message-ID: On Fri, 1 Aug 2008, Anton Shterenlikht wrote: > basically if you install port sysutils/bsdstats (just a shell script), > it will send a message from your box monthly to to bsdstats.org > with arch, os version, etc. The idea is to lobby software > producers into supporting their stuff on bsd by showing a large number > of live bsd systems. It is shame that I (and maybe a few thousand other Alpha FreeBSD users) hadn't heard of bsdstats and bsdstats.org five or more years ago. I find it amazing that the open source OS's for Alphas are deemed dead befor HP themselves have finished filling in the grave. Fruther to this non-communication/miscommunication morass, I have never upgraded my PC164 beyond FreeBSD 5 because I was led to believe that X did not work on Alpha version 6. Sheesh... It is my home workstation so I want X on it and, yes, it does help to keep me warm in the winter. As for winning the heating and power consumption war. My work station here in the office is an Alphaserver 4100 with two 600MHz CPU's and 4G of memory running OpenVMS 7.3-1. I am used to the hum and it keeps the office warm. Why VMS? Because I was abandoned by FreeBSD. -- Richard Loken VE6BSV, Unix System Administrator : "Anybody can be a father Athabasca University : but you have to earn Athabasca, Alberta Canada : the title of 'daddy'" ** richardlo@admin.athabascau.ca ** : - Lynn Johnston From wb at freebie.xs4all.nl Fri Aug 1 19:39:55 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Fri Aug 1 19:40:02 2008 Subject: future for FBSD on alpha In-Reply-To: References: <20080801153556.GA83312@mech-cluster238.men.bris.ac.uk> Message-ID: <20080801193936.GA1023@freebie.xs4all.nl> Quoting Richard Loken, who wrote on Fri, Aug 01, 2008 at 11:06:15AM -0600 .. > On Fri, 1 Aug 2008, Anton Shterenlikht wrote: > > > basically if you install port sysutils/bsdstats (just a shell script), > > it will send a message from your box monthly to to bsdstats.org > > with arch, os version, etc. The idea is to lobby software > > producers into supporting their stuff on bsd by showing a large number > > of live bsd systems. > > It is shame that I (and maybe a few thousand other Alpha FreeBSD users) > hadn't heard of bsdstats and bsdstats.org five or more years ago. I find > it amazing that the open source OS's for Alphas are deemed dead befor HP > themselves have finished filling in the grave. What do you expect here? bsdstats or not, the fact that the developer community has moved on to work on modern hardware (like on the amd64 port for example) is not related at all to how many Alphas showed up on bsdstats. Rather, the fact that the volunteer developers that make FreeBSD to what it is have voted with their feet. Nothing that bsdstats or anything else can help here. Wilko -- Wilko Bulte wilko@FreeBSD.org From ardelean at ww.uni-erlangen.de Fri Aug 1 19:56:27 2008 From: ardelean at ww.uni-erlangen.de (Gheorghe Ardelean) Date: Fri Aug 1 19:56:35 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801150833.GE1356@freebie.xs4all.nl> Message-ID: On Fri, 1 Aug 2008, Wilko Bulte wrote: > In all reality FreeBSD on Alpha is with one foot in the grave. > After FreeBSD-6.x goes EOL things are dead. IIRC by the time the decision was made someone said that it can be brought back iff developers are stepping in. In my opinion, the big problem with alpha port was that Andrew left. Hi did a very nice work porting to alphas! > It would have been better (read: it would have made survivability > of the Alpha-port a lot better) if people had voiced their interest/support > a bit earlier.. Yes, but I thing most of the users were happily running their alphas + FreeBSD. If a thing is working ok than we forget about mailing lists etc. But this happens also in other projects. IIRC a few years ago it was also a survey in Debian user community if they should keep the alpha distro. The watermark was set to ~50 users? Are we 50? Maybe yes, but as Wilko says the port needs dedicated developers with time etc. If AMD could manage to sell Athlons and Alphas for the same board (as planned) maybe we have had a better situation. Regards, Gheorghe Ardelean. From freebsd at sopwith.solgatos.com Fri Aug 1 21:52:00 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Aug 1 21:52:06 2008 Subject: future for FBSD on alpha In-Reply-To: Your message of "Fri, 01 Aug 2008 17:50:43 +0200." <20080801155042.GA1817@freebie.xs4all.nl> Message-ID: <200808012147.VAA21718@sopwith.solgatos.com> > Alpha support is gone from the cvs (well.. svn now) repository for anything > newer than RELENG_6. If you follow the cvs/svn commit messages you will > have seen that. Do you mean that someone took the time to go through and edit out support for Alpha? From naddy at mips.inka.de Fri Aug 1 22:29:48 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Fri Aug 1 22:29:55 2008 Subject: web browsers for Alpha References: <20080801091015.GA92710@mech-cluster238.men.bris.ac.uk> <200808011559.PAA01605@sopwith.solgatos.com> Message-ID: Dieter wrote: > > Being unable to build firefox3 on alpha > > Have they done anything to make firefox LP64 clean? Well, I run firefox3 on FreeBSD/amd64. In the past I've also run firefox2 on OpenBSD/amd64 and, experimentally, on OpenBSD/alpha and OpenBSD/sparc64. (The latter two machines were too slow for serious use, but it did run.) -- Christian "naddy" Weisgerber naddy@mips.inka.de From naddy at mips.inka.de Fri Aug 1 22:46:10 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Fri Aug 1 22:46:16 2008 Subject: future for FBSD on alpha References: <20080731221015.GA35293@mech-cluster238.men.bris.ac.uk> Message-ID: Anton Shterenlikht wrote: > I wonder how many people run FBSD on alpha. I did, until last weekend, when a hard disk died. FreeBSD 5.5 on an AlphaPC164. That machine held my e-mail/news setup, which I've since moved over to an amd64. > if the actual usage is indeed very small, it must be expected > that ports maintainers will stop supporting alpha soon. Your average ports maintainer has never supported alpha beyond accepting patches if you sent them any. > I'm trying to find out if there are people on this list, who, > like myself, are keen to see FBSD supported on alpha > for say 1-3 more years. FreeBSD/alpha is effectively dead. It is vestigially "supported" (= not intentionally damaged) in the 6.x branch. Meanwhile, actual progress on FreeBSD is happening in 8.0-CURRENT. Asking for _somebody_ to support alpha isn't going to accomplish anything. Either invest the work yourself or shut up. The people carrying the weight in FreeBSD development essentially gave up on alpha years ago when (or before) 6.0 was branched. I won't bother reinstalling FreeBSD 6 on my alpha. I might put OpenBSD on it, but then I already have an alpha running OpenBSD. Actually, as far as there are operating systems that still support alpha and are likely to continue doing to, OpenBSD might be your best choice. -- Christian "naddy" Weisgerber naddy@mips.inka.de From jhb at freebsd.org Sat Aug 2 02:16:05 2008 From: jhb at freebsd.org (John Baldwin) Date: Sat Aug 2 02:16:12 2008 Subject: future for FBSD on alpha In-Reply-To: <200808012147.VAA21718@sopwith.solgatos.com> References: <200808012147.VAA21718@sopwith.solgatos.com> Message-ID: <200808012215.52961.jhb@freebsd.org> On Friday 01 August 2008 09:47:30 am Dieter wrote: > > Alpha support is gone from the cvs (well.. svn now) repository for anything > > newer than RELENG_6. If you follow the cvs/svn commit messages you will > > have seen that. > > Do you mean that someone took the time to go through and edit out > support for Alpha? Yes. I did the actual deed in the kernel. I am an Alpha fan myself and have worked on it in the past (it was the first arch besides i386 to get SMPng support for example, and I worked on the DMA issues and got them fixed (I believe) just in time for 6.3). However, many other developers were not willing to expend effort on updating Alpha bits. It didn't help that they couldn't get people to test changes (such as changes to the Linux compat stuff and no one on alpha@ would test the patches). Also, the DMA issues on 6.x with ata(4) basically killed the Alpha ports cluster (that and some hardware issues). Due to all of these things Alpha was retired from 7.0-CURRENT. -- John Baldwin From wb at freebie.xs4all.nl Sat Aug 2 10:03:26 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Sat Aug 2 10:03:39 2008 Subject: future for FBSD on alpha In-Reply-To: <200808012147.VAA21718@sopwith.solgatos.com> References: <20080801155042.GA1817@freebie.xs4all.nl> <200808012147.VAA21718@sopwith.solgatos.com> Message-ID: <20080802100321.GB838@freebie.xs4all.nl> Quoting Dieter, who wrote on Fri, Aug 01, 2008 at 02:47:30PM +0100 .. > > Alpha support is gone from the cvs (well.. svn now) repository for anything > > newer than RELENG_6. If you follow the cvs/svn commit messages you will > > have seen that. > > Do you mean that someone took the time to go through and edit out > support for Alpha? Yes, when you browse the commit logs you will see that on multiple occasions Alpha-specific code has been removed. -- Wilko Bulte wilko@FreeBSD.org From naddy at mips.inka.de Sat Aug 2 17:01:32 2008 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat Aug 2 17:01:39 2008 Subject: firefox3 build fails on alpha References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> Message-ID: Anton Shterenlikht wrote: > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > In this particular case it seems that (at least) 2 files > are missing from the distribution: > > xptcinvoke_freebsd_alpha.cpp > xptcstubs_freebsd_alpha.cpp Yes. These need to be created. You have stumbled on a dirty secret: the Mozilla family programs rely on a part that must be ported at the assembly(!) language level to each processor/compiler/(operating system) combination. > I think that whoever created the tar file simply forgot to add the freebsd > files. No, somebody needs to write them. -- Christian "naddy" Weisgerber naddy@mips.inka.de From ardelean at ww.uni-erlangen.de Sun Aug 3 00:17:32 2008 From: ardelean at ww.uni-erlangen.de (Gheorghe Ardelean) Date: Sun Aug 3 00:17:39 2008 Subject: local builded packages for 6.3-RELEASE uploaded Message-ID: Hi, I have uploaded ~400 packages that I have built on my Alphas running FreeBSD 6.3-RELEASE. Among them are: xorg, firefox, thunderbird, xpdf, teTeX, emacs, python etc. Please feel free to use them from here: ftp://ftp.ro.freebsd.org/pub/FreeBSD/ports/alpha/packages-6.3-release-local I suppose I am not allowed to make symbolic links from the release directory to them, so they do not appear in FreeBSD mirror sites database here: http://mirrorlist.freebsd.org/FBSDsites.php Best regards, Gheorghe Ardelean. From mexas at bristol.ac.uk Sun Aug 3 13:58:21 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Aug 3 13:58:28 2008 Subject: xptcinvoke_freebsd_alpha.cpp and xptcstubs_freebsd_alpha.cpp for firefox3 ? Message-ID: <20080803135813.GA31646@mech-cluster238.men.bris.ac.uk> Hi Glen (copied to freebsd-alpha mailing list). I'm writing you as a contributor of the above 2 files for firefox2. I tried to build firefox3 on alpha by simply copying them as is from firefox2 to firefox3. While xptcinvoke compiles with no warnings, xptctubs fails with: c++ -o xptcstubs_freebsd_alpha.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD6\ " -DOSARCH=FreeBSD -DEXPORT_XPTC_API -D_IMPL_NS_COM -I./../.. -I./../../../../xp tinfo/src -I. -I. -I../../../../../../dist/include/string -I../../../../../../d ist/include -I../../../../../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/loca l/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloa ded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -W no-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-alia sing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -I/usr/local/include -I/usr/lo cal/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h xptcstu bs_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp: In function `nsresult PrepareAndDispatch(nsXPTCStub Base*, uint32, PRUint64*)': xptcstubs_freebsd_alpha.cpp:59: error: `nsIInterfaceInfo' was not declared in th is scope xptcstubs_freebsd_alpha.cpp:59: error: `iface_info' was not declared in this sco pe xptcstubs_freebsd_alpha.cpp:67: error: 'class nsXPTCStubBase' has no member name d 'GetInterfaceInfo' xptcstubs_freebsd_alpha.cpp:131: error: 'class nsXPTCStubBase' has no member nam ed 'CallMethod' xptcstubs_freebsd_alpha.cpp:59: warning: unused variable 'nsIInterfaceInfo' gmake[8]: *** [xptcstubs_freebsd_alpha.o] Error 1 Could you please comment on this. How much should these files change from firefox2 to firefox3 on freebsd alpha? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Aug 3 14:27:39 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Aug 3 14:27:46 2008 Subject: xptcinvoke_freebsd_alpha.cpp and xptcstubs_freebsd_alpha.cpp for firefox3 ? In-Reply-To: <20080803135813.GA31646@mech-cluster238.men.bris.ac.uk> References: <20080803135813.GA31646@mech-cluster238.men.bris.ac.uk> Message-ID: <20080803142733.GB32357@mech-cluster238.men.bris.ac.uk> On Sun, Aug 03, 2008 at 02:58:13PM +0100, Anton Shterenlikht wrote: > Hi Glen > > (copied to freebsd-alpha mailing list). > > I'm writing you as a contributor of the above 2 files for firefox2. Glen's email bounced back, the address in unknown. Apparently he has "seemingly disappeared from the face of the earth" according to http://www.mozilla.org/MPL/missing.html He was "fould" Jonas Jorgensen (jonasj@jonasj.dk), but that email bounces back as well. If, by any chance, somebody on this list knows how to contact Glen Nakamura, please let me know. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Aug 3 18:55:52 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Aug 3 18:55:59 2008 Subject: xptcinvoke and xptcstubs for firefox3 on FreeBSD Alpha In-Reply-To: <20080803171000.GA30383@modulo.internal> References: <20080803164656.GA5775@mech-cluster238.men.bris.ac.uk> <20080803171000.GA30383@modulo.internal> Message-ID: <20080803185545.GA6782@mech-cluster238.men.bris.ac.uk> On Sun, Aug 03, 2008 at 07:10:00AM -1000, Glen Nakamura wrote: > On Sun, Aug 03, 2008 at 05:46:56PM +0100, Anton Shterenlikht wrote: > > I'm trying to trace Glen Nakamura, a contributor to firefox, > > regarding some of his code. > > > > If it is the same Glen who holds the copyright to your site, > > please put me in touch with him. > > Aloha Anton, > > I contributed the Linux Alpha port of the xptcall interface > to the Mozilla project... What piece of code are you inquiring about? Glen, many thanks for a quick reply. (copied to freebsd-alpha mailing list) I'm trying to build firefox3 on FreeBSD Alpha. The build fails because files xptcinvoke_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp (at least these 2, there might be more) are missing from the distribution. I understand you wrote the code in these files for firefox2. I've build firefox2 fine on the same machine, and I decided to just copy these 2 files from firefox2 source tree to firerox3 as is. The build fails with the following error: gmake[8]: Entering directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect /xptcall/src/md/unix' xptcinvoke_freebsd_alpha.cpp c++ -o xptcinvoke_freebsd_alpha.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD6 \" -DOSARCH=FreeBSD -DEXPORT_XPTC_API -D_IMPL_NS_COM -I./../.. -I./../../../../x ptinfo/src -I. -I. -I../../../../../../dist/include/string -I../../../../../../ dist/include -I../../../../../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/loc al/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverlo aded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align - Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-ali asing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -I/usr/local/include -I/usr/l ocal/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h xptcin voke_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp c++ -o xptcstubs_freebsd_alpha.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD6\ " -DOSARCH=FreeBSD -DEXPORT_XPTC_API -D_IMPL_NS_COM -I./../.. -I./../../../../xp tinfo/src -I. -I. -I../../../../../../dist/include/string -I../../../../../../d ist/include -I../../../../../../dist/include/xpcom -I/usr/local/include/nspr -I/usr/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/loca l/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloa ded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -W no-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-alia sing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -I/usr/local/include -I/usr/lo cal/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h xptcstu bs_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp: In function `nsresult PrepareAndDispatch(nsXPTCStub Base*, uint32, PRUint64*)': xptcstubs_freebsd_alpha.cpp:59: error: `nsIInterfaceInfo' was not declared in th is scope xptcstubs_freebsd_alpha.cpp:59: error: `iface_info' was not declared in this sco pe xptcstubs_freebsd_alpha.cpp:67: error: 'class nsXPTCStubBase' has no member name d 'GetInterfaceInfo' xptcstubs_freebsd_alpha.cpp:131: error: 'class nsXPTCStubBase' has no member nam ed 'CallMethod' xptcstubs_freebsd_alpha.cpp:59: warning: unused variable 'nsIInterfaceInfo' gmake[8]: *** [xptcstubs_freebsd_alpha.o] Error 1 gmake[8]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/ xptcall/src/md/unix' gmake[7]: *** [libs] Error 2 So, it seems xptcinvoke compiles fine, but xptcstubs fails. Could you please give brief explanation of what the code in these files actually does, or point to a manual/doc if possible. I'm not a programmer myself, particularly not an assembler person, so reading the files didn't give me much insight. I had a very brief look at the distribution tree and I believe these 2 files are generated during configure stage from ./files/patch-xptcall-alpha, which is also missing in firefox3 distribution. Please comment on this as well if you can. Finally, how much work do you think is needed to port these 2 files from firefox2 to firefox3? Is it really just 2 files, or there is much more work to be done? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Sun Aug 3 21:43:22 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Sun Aug 3 21:43:29 2008 Subject: xptcinvoke and xptcstubs for firefox3 on FreeBSD Alpha Message-ID: <20080803214316.GA15206@mech-cluster238.men.bris.ac.uk> I guess I have to study xptcall, see below. anton ----- Forwarded message from Glen Nakamura ----- Date: Sun, 3 Aug 2008 10:13:55 -1000 From: Glen Nakamura To: Anton Shterenlikht Subject: Re: xptcinvoke and xptcstubs for firefox3 on FreeBSD Alpha On Sun, Aug 03, 2008 at 07:55:46PM +0100, Anton Shterenlikht wrote: > Glen, many thanks for a quick reply. > > (copied to freebsd-alpha mailing list) > > I'm trying to build firefox3 on FreeBSD Alpha. > The build fails because files > > xptcinvoke_freebsd_alpha.cpp > xptcstubs_freebsd_alpha.cpp > > (at least these 2, there might be more) are missing from the distribution. > I understand you wrote the code in these files for firefox2. To clarify, I contributed: xptcinvoke_linux_alpha.cpp xptcstubs_linux_alpha.cpp These files may have been the basis for ports to other operating systems which were contributed by other people. In fact, I don't see any references to the xptc*_freebsd_alpha.cpp files in the standard source. The Makefile contains: # # Linux/Alpha # ifneq (,$(filter Linuxalpha FreeBSDalpha NetBSDalpha,$(OS_ARCH)$(OS_TEST))) CPPSRCS := xptcinvoke_linux_alpha.cpp xptcstubs_linux_alpha.cpp endif This seems to imply that FreeBSD would use the same files as Linux for the Alpha architecture. > I've build firefox2 fine on the same machine, and I decided > to just copy these 2 files from firefox2 source tree to > firerox3 as is. The build fails with the following error: [snip] > > So, it seems xptcinvoke compiles fine, but xptcstubs fails. > > Could you please give brief explanation of what the code > in these files actually does, or point to a manual/doc if > possible. I'm not a programmer myself, particularly not > an assembler person, so reading the files didn't give me > much insight. Information about xptcall can be found at: http://developer.mozilla.org/en/docs/xptcall_FAQ A porting guide is also available: http://mxr.mozilla.org/mozilla/source/xpcom/reflect/xptcall/porting.html > I had a very brief look at the distribution tree > and I believe these 2 files are generated during > configure stage from ./files/patch-xptcall-alpha, > which is also missing in firefox3 distribution. > Please comment on this as well if you can. If you're working with FreeBSD specific patched source, I don't know how much help I can provide you... You could look at the differences between the FreeBSD and Linux versions of the files you have, and also the differences (if any) between the Firefox 2 and Firefox 3 versions. You might want to look closer at changes to the Makefile[.in] file. > Finally, how much work do you think is needed to port these 2 files > from firefox2 to firefox3? Is it really just 2 files, or > there is much more work to be done? There may have been changes in the build mechanics, but I don't think much has changed in the design and implementation of the xptcall interface. Of course, I haven't been actively involved in Firefox development so things may have changed without me noticing. - Glen Nakamura ----- End forwarded message ----- -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From bugmaster at FreeBSD.org Mon Aug 4 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:07:05 2008 Subject: Current problem reports assigned to freebsd-alpha@FreeBSD.org Message-ID: <200808041106.m74B6psX081983@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/61940 alpha [sysinstall] Can't disklabel new disk from FreeBSD/alp o alpha/61973 alpha Machine Check on boot-up of AlphaServer 2100A RM s alpha/67626 alpha X crashes an alpha machine, resulting reboot o alpha/85346 alpha PREEMPTION causes unstability in Alpha4000 SMP kernel o alpha/105134 alpha 'panic: lockmgr: thread ... not exclusive lock owner' 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/25284 alpha PC164 won't reboot with graphics console o alpha/38031 alpha osf1.ko not loaded during boot-time of linux-emu enabl o alpha/48676 alpha Changing the baud rate of serial consoles for Alpha sy o alpha/67903 alpha hw.chipset.memory: 1099511627776 - thats way to much : 4 problems total. From jhb at freebsd.org Mon Aug 4 14:08:08 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 4 14:08:32 2008 Subject: firefox3 build fails on alpha In-Reply-To: <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> Message-ID: <200808040909.09020.jhb@freebsd.org> On Friday 01 August 2008 04:55:27 am Anton Shterenlikht wrote: > On Thu, Jul 31, 2008 at 05:42:17PM -0500, Jeremy Messenger wrote: > > On Thu, 31 Jul 2008 17:24:43 -0500, Anton Shterenlikht > > > > wrote: > > > On Sun, Jul 13, 2008 at 12:59:29AM +0200, Wilko Bulte wrote: > > >> Quoting Jeremy Messenger, who wrote on Sat, Jul 12, 2008 at 05:44:11PM > > >> -0500 .. > > >> > > >> > On Tue, 08 Jul 2008 07:23:52 -0500, Anton Shterenlikht > > >> > > > >> > wrote: > > >> > > A followup. It seems xptcinvoke_freebsd_alpha.cpp is missing. It > > >> > > is used in Makefile: > > >> > > > >> > I think most of us don't have any alpha machine. You might have to > > >> > > >> create > > >> > > >> > patch for us. I think, the alpha support has been dropped so it's > > >> > pointless for us to work on alpha support. > > >> > > >> The latest release of FreeBSD supporting the Alpha platform port is > > >> RELENG_6. Anything newer no longer supports Alpha. > > > > > > I'm happy with RELENG_6 on alpha. > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > In this particular case it seems that (at least) 2 files > > > are missing from the distribution: > > > > > > xptcinvoke_freebsd_alpha.cpp > > > xptcstubs_freebsd_alpha.cpp > > > > > > (curiously the corresponding *alpha.cpp files are present for osf1, > > > linux, > > > openvms and openbsd). > > > > > > I think that whoever created the tar file simply forgot to add the > > > freebsd > > > files. > > > > > > I did try to contact mozilla developers directly, but no reply so far. > > > I understand that mozilla developers put out the tar file. Perhaps the > > > port maintainers could alert the mozilla team about the missing files, > > > or maybe even get these 2 files. I'd be very greatful. > > > > Have you tried 3.0.1 yet? The Makefile.in has changed by Mozilla team: > > > > --------------------------------------------------- > > ###################################################################### > > # > > # Tru64/Alpha > > # > > ifeq ($(OS_ARCH)$(OS_TEST),OSF1alpha) > > CPPSRCS := xptcinvoke_osf1_alpha.cpp xptcstubs_osf1_alpha.cpp > > ASFILES := xptcinvoke_asm_osf1_alpha.s xptcstubs_asm_osf1_alpha.s > > endif > > # > > # Linux/Alpha > > # > > ifneq (,$(filter Linuxalpha FreeBSDalpha > > NetBSDalpha,$(OS_ARCH)$(OS_TEST))) CPPSRCS := xptcinvoke_linux_alpha.cpp > > xptcstubs_linux_alpha.cpp endif > > --------------------------------------------------- > > > > But I have no idea if it works. > > I just tried again, and get the same error: > > gmake[8]: Entering directory > `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect /xptcall/src/md/unix' > gmake[8]: *** No rule to make target `xptcinvoke_freebsd_alpha.o', needed > by `li bxptcmd.a'. Stop. > gmake[8]: Leaving directory > `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/ xptcall/src/md/unix' > gmake[7]: *** [libs] Error 2 > > Also my Makefile.in under > /usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md/unix > > still requires these 2 files: > > ###################################################################### > # Alpha > ###################################################################### > # > > [skip] > > # > # FreeBSD/Alpha > # > ifeq ($(OS_ARCH)$(OS_TEST),FreeBSDalpha) > CPPSRCS := xptcinvoke_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp > endif > > which are missing: I would compare the FreeBSD and Linux files in the www/firefox port and see what differences there are and try to apply this differences to the Linux files in www/firefox3 to generate FreeBSD files for www/firefox3. -- John Baldwin From mexas at bristol.ac.uk Tue Aug 5 08:26:24 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Aug 5 08:26:31 2008 Subject: firefox3 build fails on alpha - 1 file fixed In-Reply-To: <200808040909.09020.jhb@freebsd.org> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080801085527.GA84573@mech-cluster238.men.bris.ac.uk> <200808040909.09020.jhb@freebsd.org> Message-ID: <20080805082613.GA93671@mech-cluster238.men.bris.ac.uk> On Mon, Aug 04, 2008 at 09:09:08AM -0400, John Baldwin wrote: > On Friday 01 August 2008 04:55:27 am Anton Shterenlikht wrote: > > On Thu, Jul 31, 2008 at 05:42:17PM -0500, Jeremy Messenger wrote: > > > On Thu, 31 Jul 2008 17:24:43 -0500, Anton Shterenlikht > > > > > > wrote: > > > > On Sun, Jul 13, 2008 at 12:59:29AM +0200, Wilko Bulte wrote: > > > >> Quoting Jeremy Messenger, who wrote on Sat, Jul 12, 2008 at 05:44:11PM > > > >> -0500 .. > > > >> > > > >> > On Tue, 08 Jul 2008 07:23:52 -0500, Anton Shterenlikht > > > >> > > > > >> > wrote: > > > >> > > A followup. It seems xptcinvoke_freebsd_alpha.cpp is missing. It > > > >> > > is used in Makefile: > > > >> > > > > >> > I think most of us don't have any alpha machine. You might have to > > > >> > > > >> create > > > >> > > > >> > patch for us. I think, the alpha support has been dropped so it's > > > >> > pointless for us to work on alpha support. > > > >> > > > >> The latest release of FreeBSD supporting the Alpha platform port is > > > >> RELENG_6. Anything newer no longer supports Alpha. > > > > > > > > I'm happy with RELENG_6 on alpha. > > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > > > In this particular case it seems that (at least) 2 files > > > > are missing from the distribution: > > > > > > > > xptcinvoke_freebsd_alpha.cpp > > > > xptcstubs_freebsd_alpha.cpp > > > > > > > > (curiously the corresponding *alpha.cpp files are present for osf1, > > > > linux, > > > > openvms and openbsd). > > > > > > > > I think that whoever created the tar file simply forgot to add the > > > > freebsd > > > > files. > > > > > > > > I did try to contact mozilla developers directly, but no reply so far. > > > > I understand that mozilla developers put out the tar file. Perhaps the > > > > port maintainers could alert the mozilla team about the missing files, > > > > or maybe even get these 2 files. I'd be very greatful. > > > > > > Have you tried 3.0.1 yet? The Makefile.in has changed by Mozilla team: > > > > > > --------------------------------------------------- > > > ###################################################################### > > > # > > > # Tru64/Alpha > > > # > > > ifeq ($(OS_ARCH)$(OS_TEST),OSF1alpha) > > > CPPSRCS := xptcinvoke_osf1_alpha.cpp xptcstubs_osf1_alpha.cpp > > > ASFILES := xptcinvoke_asm_osf1_alpha.s xptcstubs_asm_osf1_alpha.s > > > endif > > > # > > > # Linux/Alpha > > > # > > > ifneq (,$(filter Linuxalpha FreeBSDalpha > > > NetBSDalpha,$(OS_ARCH)$(OS_TEST))) CPPSRCS := xptcinvoke_linux_alpha.cpp > > > xptcstubs_linux_alpha.cpp endif > > > --------------------------------------------------- > > > > > > But I have no idea if it works. > > > > I just tried again, and get the same error: > > > > gmake[8]: Entering directory > > `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect /xptcall/src/md/unix' > > gmake[8]: *** No rule to make target `xptcinvoke_freebsd_alpha.o', needed > > by `li bxptcmd.a'. Stop. > > gmake[8]: Leaving directory > > `/usr/ports/www/firefox3/work/mozilla/xpcom/reflect/ xptcall/src/md/unix' > > gmake[7]: *** [libs] Error 2 > > > > Also my Makefile.in under > > /usr/ports/www/firefox3/work/mozilla/xpcom/reflect/xptcall/src/md/unix > > > > still requires these 2 files: > > > > ###################################################################### > > # Alpha > > ###################################################################### > > # > > > > [skip] > > > > # > > # FreeBSD/Alpha > > # > > ifeq ($(OS_ARCH)$(OS_TEST),FreeBSDalpha) > > CPPSRCS := xptcinvoke_freebsd_alpha.cpp xptcstubs_freebsd_alpha.cpp > > endif > > > > which are missing: > > I would compare the FreeBSD and Linux files in the www/firefox port and see > what differences there are and try to apply this differences to the Linux > files in www/firefox3 to generate FreeBSD files for www/firefox3. John, thank you. I did just that and it seems to have worked. I had only to remove 7 lines and add 2. Now xptctubs compiles fine. The build now fails at another file (see below), so I won't submit a patch yet. However, if anybody is interested I can post the corrected patch-xptcall-alpha here. By the way patch-xptcall-sparc64 from firefox2 port is not present in firefox3 port, therefore I assume firefox3 build also fails on freebsd sparc64. The new failure point: gmake[5]: Entering directory `/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src' nsCookieService.cpp c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/storage -I../../../dist/include -I../../../dist/include/necko -I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h nsCookieService.cpp ../../../dist/include/xpcom/nsTHashtable.h: In static member function `static PRBool nsTHashtable::s_MatchEntry(PLDHashTable*, const PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]': ../../../dist/include/xpcom/nsTHashtable.h:335: instantiated from `PRBool nsTHashtable::Init(PRUint32) [with EntryType = nsCookieEntry]' nsCookieService.cpp:418: instantiated from here ../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type gmake[5]: *** [nsCookieService.o] Error 1 I'm not sure if the problem is with nsCookieService.cpp or nsTHashtable.h thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From pfgshield-freebsd at yahoo.com Wed Aug 6 03:13:25 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Wed Aug 6 03:44:45 2008 Subject: future for FBSD on alpha In-Reply-To: <20080801120440.GA29656@mech-cluster238.men.bris.ac.uk> Message-ID: <229131.20291.qm@web32708.mail.mud.yahoo.com> FWIW; I think it would be interesting to do some LLVM testing on Alpha. Like here: http://wiki.freebsd.org/LowLevelVirtualMachine/ check the devel/llvm port and run make MAINTAINER_MODE=yes regression-target then report bugs to the llvm developers. This won't resurrect FreeBSD-Alpha, but I do think it would make the EOL release interesting and usable for a while longer. cheers, Pedro. Posta, news, sport, oroscopo: tutto in una sola pagina. Crea l'home page che piace a te! www.yahoo.it/latuapagina From mexas at bristol.ac.uk Wed Aug 6 08:54:20 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Wed Aug 6 08:55:48 2008 Subject: future for FBSD on alpha In-Reply-To: <229131.20291.qm@web32708.mail.mud.yahoo.com> References: <20080801120440.GA29656@mech-cluster238.men.bris.ac.uk> <229131.20291.qm@web32708.mail.mud.yahoo.com> Message-ID: <20080806085413.GA9222@mech-cluster238.men.bris.ac.uk> On Tue, Aug 05, 2008 at 08:13:24PM -0700, Pedro Giffuni wrote: > FWIW; > > I think it would be interesting to do some LLVM testing on Alpha. Like here: > > http://wiki.freebsd.org/LowLevelVirtualMachine/ > > check the devel/llvm port and run > > make MAINTAINER_MODE=yes regression-target > then report bugs to the llvm developers. Given all that was said in this thread before, I doubt any llvm developer is interested in RELENG_6 branch. As far as I'm concerned this is just a port like any other, and a port that I don't use. Even if it builds fine and passes all tests, I can't see much use. Or, perhaps, I'm missing something. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From pfgshield-freebsd at yahoo.com Wed Aug 6 15:05:34 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Wed Aug 6 15:27:20 2008 Subject: future for FBSD on alpha In-Reply-To: <20080806085413.GA9222@mech-cluster238.men.bris.ac.uk> Message-ID: <753340.1081.qm@web32705.mail.mud.yahoo.com> --- Mer 6/8/08, Anton Shterenlikht ha scritto: ... > > Or, perhaps, I'm missing something. > Future of FreeBSD on Alpha is death, but you are missing the signs of times: - LLVM is about providing a better compiler infrastructure under a BSD-like license. They support FreeBSD and have an Alpha backend. - The latest versions of GCC are under the GPLv3, which is being avoided by FreeBSD and other projects, at least for the immediate future. FreeBSD-Alpha bugs may not be specific to FreeBSD, but of course if no one cares to report problems they won't get fixed and eventually they will drop support too. FWIW, more info on LLVM specific to FreeBSD: http://www.bsdcan.org/2008/schedule/track/Invited%20Talks/99.en.html cheers, Pedro. Posta, news, sport, oroscopo: tutto in una sola pagina. Crea l'home page che piace a te! www.yahoo.it/latuapagina From gerald at pfeifer.com Sat Aug 9 22:32:01 2008 From: gerald at pfeifer.com (Gerald Pfeifer) Date: Sat Aug 9 22:32:07 2008 Subject: lang/gcc42 on alpha In-Reply-To: <20080731215803.GA35238@mech-cluster238.men.bris.ac.uk> References: <20080708091924.GA9171@mech-cluster238.men.bris.ac.uk> <20080731215803.GA35238@mech-cluster238.men.bris.ac.uk> Message-ID: On Thu, 31 Jul 2008, Anton Shterenlikht wrote: > Yes, please do this. I'm happy to help with testing. I had done it already :-), and no problems for three weeks at least. Gerald From bugmaster at FreeBSD.org Mon Aug 11 11:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:07:04 2008 Subject: Current problem reports assigned to freebsd-alpha@FreeBSD.org Message-ID: <200808111106.m7BB6rhW047110@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/61940 alpha [sysinstall] Can't disklabel new disk from FreeBSD/alp o alpha/61973 alpha Machine Check on boot-up of AlphaServer 2100A RM s alpha/67626 alpha X crashes an alpha machine, resulting reboot o alpha/85346 alpha PREEMPTION causes unstability in Alpha4000 SMP kernel o alpha/105134 alpha 'panic: lockmgr: thread ... not exclusive lock owner' 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/25284 alpha PC164 won't reboot with graphics console o alpha/38031 alpha osf1.ko not loaded during boot-time of linux-emu enabl o alpha/48676 alpha Changing the baud rate of serial consoles for Alpha sy o alpha/67903 alpha hw.chipset.memory: 1099511627776 - thats way to much : 4 problems total. From bsd at hackbox.bunker-ranch.org Fri Aug 15 21:25:19 2008 From: bsd at hackbox.bunker-ranch.org (Terry R. Friedrichsen) Date: Fri Aug 15 21:25:30 2008 Subject: future for FBSD on alpha In-Reply-To: <8F8C8CFE62002A4EB82EE1CE9F2ED7D40ECACD@depot.AxxisCorp.local> Message-ID: <200808152050.m7FKonc4096597@hackbox.bunker-ranch.org> I run several FreeBSD/alpha machines. I've had 6.2 fail to install on at least one of them. I, too, would like to see support into the future, though I guess it doesn't look too hopeful. Terry R. Friedrichsen bsd@bunker-ranch.com From ticso at cicely7.cicely.de Sat Aug 16 16:34:00 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sat Aug 16 16:34:07 2008 Subject: firefox3 build fails on alpha In-Reply-To: References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> Message-ID: <20080816161820.GG37139@cicely7.cicely.de> On Sat, Aug 02, 2008 at 05:01:23PM +0000, Christian Weisgerber wrote: > Anton Shterenlikht wrote: > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > In this particular case it seems that (at least) 2 files > > are missing from the distribution: > > > > xptcinvoke_freebsd_alpha.cpp > > xptcstubs_freebsd_alpha.cpp > > Yes. These need to be created. > > You have stumbled on a dirty secret: the Mozilla family programs > rely on a part that must be ported at the assembly(!) language level > to each processor/compiler/(operating system) combination. > > > I think that whoever created the tar file simply forgot to add the freebsd > > files. > > No, somebody needs to write them. I wrote them a few years back for mozilla and they were part of the port. Don't know what happened in the meantime, because since alpha support is removed I stopped spending time into it. The whole xptcinvoke thing is completely breandead anyway. The intention was to have a portable interfacing to modules, but in fact they just read the C++ vtable using assembly, which the compiler can do without any help. The assembly calling functions need to know the compiler specific vtable and not a fixed self defined, which is not what I expected to see. It took me several days to understand that they want something senseless. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From mexas at bristol.ac.uk Mon Aug 18 08:37:25 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Aug 18 08:37:37 2008 Subject: firefox3 build fails on alpha In-Reply-To: <20080816161820.GG37139@cicely7.cicely.de> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <20080816161820.GG37139@cicely7.cicely.de> Message-ID: <20080818083712.GA1032@mech-cluster238.men.bris.ac.uk> On Sat, Aug 16, 2008 at 06:18:20PM +0200, Bernd Walter wrote: > On Sat, Aug 02, 2008 at 05:01:23PM +0000, Christian Weisgerber wrote: > > Anton Shterenlikht wrote: > > > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > In this particular case it seems that (at least) 2 files > > > are missing from the distribution: > > > > > > xptcinvoke_freebsd_alpha.cpp > > > xptcstubs_freebsd_alpha.cpp > > > > Yes. These need to be created. > > > > You have stumbled on a dirty secret: the Mozilla family programs > > rely on a part that must be ported at the assembly(!) language level > > to each processor/compiler/(operating system) combination. > > > > > I think that whoever created the tar file simply forgot to add the freebsd > > > files. > > > > No, somebody needs to write them. > > I wrote them a few years back for mozilla and they were part of the port. > Don't know what happened in the meantime, because since alpha support is > removed I stopped spending time into it. > The whole xptcinvoke thing is completely breandead anyway. > The intention was to have a portable interfacing to modules, but in fact > they just read the C++ vtable using assembly, which the compiler can do > without any help. > The assembly calling functions need to know the compiler specific > vtable and not a fixed self defined, which is not what I expected to see. > It took me several days to understand that they want something senseless. Anyway, I seem to have fixed this. The build now passes this stage but fails at another. The mozilla developers 'don't know' how to fix it, and apparently lost the interest. Anybody here cares to comment? Something to do with incorrect alignment. Please see below the bugzilla thread. https://bugzilla.mozilla.org/show_bug.cgi?id=449373 "I'm building firefox3.0.1 on FreeBSD-6.3-stable Alpha. I get this error message: gmake[5]: Entering directory `/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src' nsCookieService.cpp c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/storage -I../../../dist/include -I../../../dist/include/necko -I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h nsCookieService.cpp ../../../dist/include/xpcom/nsTHashtable.h: In static member function `static PRBool nsTHashtable::s_MatchEntry(PLDHashTable*, const PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]': ../../../dist/include/xpcom/nsTHashtable.h:335: instantiated from `PRBool nsTHashtable::Init(PRUint32) [with EntryType = nsCookieEntry]' nsCookieService.cpp:418: instantiated from here ../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type gmake[5]: *** [nsCookieService.o] Error 1 Reproducible: Always Steps to Reproduce: 1. get FreeBSD-6.3-Alpha 2. cd /usr/ports/www/firefox3 3. make Actual Results: ../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type I believe this warning indicates a problem that leads to failure of compilation of nsCookieService.cpp Comment #1 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-06 07:57:51 PDT This is an interesting bug, and it may be "real" in some sense. nsTHashtable is a wrapper around the pldhash code, which places entries (which begin with or are derived from PLDHashEntryHdr) in a contiguous array. It uses sizeof(entry) as the entry size, which may not be the same as the required alignment for the entry type. What is the required alignment of nsCookieEntry and PLDHashEntryHdr? Is there a way for the compiler to tell us what the required alignment is? If so, we may need to extend the entry size to the required alignment. In that case we "know" that the PLDHashEntryHdr* is of the required alignment, and this cast should be safe... then how do we tell the compiler that it's a safe cast? In an private mail from Anton he says that this worked in FF2 but broke in FF3 because previously we were using NS_REINTERPRET_CAST and we're now using reinterpret_cast<>(), but these should have been equivalent on any modern C++ compiler. Also, it seems like this could be a static_cast instead of a reinterpret_cast, since in nsTHashtable the entry types are always derivatives. I can provide a patch to that effect to see if it helps. Comment #2 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-06 09:09:44 PDT Created an attachment (id=332545) [details] nsTHashtable use static_cast and not reinterpret_cast, rev. 1 Anton, please try this patch and let me know whether it helps. Comment #4 [reply] Anton Shterenlikht 2008-08-07 02:00:12 PDT I saved the patch into /usr/ports/www/firefox3/work/mozilla/xpcom/glue/ns/nsTHashtable.h.patch Then I did # patch < nsTHashtable.h.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xpcom/glue/nsTHashtable.h b/xpcom/glue/nsTHashtable.h |--- a/xpcom/glue/nsTHashtable.h |+++ b/xpcom/glue/nsTHashtable.h -------------------------- Patching file nsTHashtable.h using Plan A... Hunk #1 succeeded at 157 (offset -6 lines). Hunk #2 succeeded at 355 (offset -6 lines). Hunk #3 succeeded at 365 (offset -6 lines). Hunk #4 succeeded at 375 (offset -6 lines). Hunk #5 succeeded at 387 (offset -6 lines). Hunk #6 succeeded at 396 (offset -6 lines). Hunk #7 succeeded at 408 (offset -6 lines). Hmm... Ignoring the trailing garbage. done # The error message is very similar, if not the same: gmake[5]: Entering directory `/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src' nsCookieService.cpp c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/storage -I../../../dist/include -I../../../dist/include/necko -I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include -I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror -I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h nsCookieService.cpp ../../../dist/include/xpcom/nsTHashtable.h: In static member function `static PRBool nsTHashtable::s_MatchEntry(PLDHashTable*, const PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]': ../../../dist/include/xpcom/nsTHashtable.h:334: instantiated from `PRBool nsTHashtable::Init(PRUint32) [with EntryType = nsCookieEntry]' nsCookieService.cpp:418: instantiated from here ../../../dist/include/xpcom/nsTHashtable.h:367: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type gmake[5]: *** [nsCookieService.o] Error 1 thanks anton Comment #5 [reply] Anton Shterenlikht 2008-08-07 05:08:01 PDT Also, in case it matters, the compiler versions are: # gcc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 # # gcc42 -v Using built-in specs. Target: alpha-portbld-freebsd6.3 Configured with: ./..//gcc-4.2-20080702/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local --program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.5 --with-gxx-include-dir=/usr/local/lib/gcc-4.2.5/include/c++/ --disable-libgcj --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc42 alpha-portbld-freebsd6.3 Thread model: posix gcc version 4.2.5 20080702 (prerelease) # I believe freebsd3 port is being built with the system compiler, i.e. 3.4.6. anton Comment #6 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-07 05:27:34 PDT In that case, I do not know how to fix this bug... I'm almost certain the error is bogus, since we know that the PLDHashEntryHdr* is the correct alignment (confirmed using sizeof()), but I don't know how to inform the compiler that this cast should be allowed. Comment #7 [reply] Mike Shaver 2008-08-07 05:42:08 PDT How do you confirm alignment with sizeof? Comment #8 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-07 05:56:30 PDT >From experiments, it seems that sizeof(struct) is always a multiple of the necessary alignment for that struct. The pldhash entry store is malloced (which has perfect alignment) and entries are on sizeof(struct) boundaries within the allocation, so I believe that in reality they are always correctly aligned. Shaver says: "I guess you want to cast via void*"... which makes me sad! " -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From mexas at bristol.ac.uk Mon Aug 18 08:47:56 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Aug 18 08:48:11 2008 Subject: ports/ImageMagick -> Magick++ -> 2 tests fail on FBSD 6.3 alpha In-Reply-To: <20080710031113.15021tn1pjxnrs1d@mail.vx.sk> References: <20080709164316.GA50703@mech-cluster238.men.bris.ac.uk> <20080710031113.15021tn1pjxnrs1d@mail.vx.sk> Message-ID: <20080818084746.GA1173@mech-cluster238.men.bris.ac.uk> On Thu, Jul 10, 2008 at 03:11:13AM +0200, Martin Matuska wrote: > Hi, > > I am on a vacation abroad until July, 23. I will take care of my ports > after returning. > Hi Martin Just to let you know that the failures occur in ImageMagick-6.4.2.7 just the same. anton > Quoting "Anton Shterenlikht" : > > > Two ImageMagick tests fail with core dumps on my FBSD 6.3 alpha: > > > > FAIL: Magick++/tests/exceptions.sh > > FAIL: Magick++/tests/attributes.sh > > > > They pass on my FBSD 7.0 i386. > > > > exceptions.cpp actually warns: > > > > %vi exceptions.cpp > > > > [skip] > > > > 22 > > 23 cout << "Checking for working exceptions (may crash) ... "; > > 24 > > > > Is this to do with different c++ versions on FBSD 7 and 6? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From ticso at cicely7.cicely.de Mon Aug 18 09:39:37 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Mon Aug 18 09:39:48 2008 Subject: firefox3 build fails on alpha In-Reply-To: <20080818083712.GA1032@mech-cluster238.men.bris.ac.uk> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <20080816161820.GG37139@cicely7.cicely.de> <20080818083712.GA1032@mech-cluster238.men.bris.ac.uk> Message-ID: <20080818093918.GE6331@cicely7.cicely.de> On Mon, Aug 18, 2008 at 09:37:12AM +0100, Anton Shterenlikht wrote: > On Sat, Aug 16, 2008 at 06:18:20PM +0200, Bernd Walter wrote: > > On Sat, Aug 02, 2008 at 05:01:23PM +0000, Christian Weisgerber wrote: > > > Anton Shterenlikht wrote: > > > > > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > > > In this particular case it seems that (at least) 2 files > > > > are missing from the distribution: > > > > > > > > xptcinvoke_freebsd_alpha.cpp > > > > xptcstubs_freebsd_alpha.cpp > > > > > > Yes. These need to be created. > > > > > > You have stumbled on a dirty secret: the Mozilla family programs > > > rely on a part that must be ported at the assembly(!) language level > > > to each processor/compiler/(operating system) combination. > > > > > > > I think that whoever created the tar file simply forgot to add the freebsd > > > > files. > > > > > > No, somebody needs to write them. > > > > I wrote them a few years back for mozilla and they were part of the port. > > Don't know what happened in the meantime, because since alpha support is > > removed I stopped spending time into it. > > The whole xptcinvoke thing is completely breandead anyway. > > The intention was to have a portable interfacing to modules, but in fact > > they just read the C++ vtable using assembly, which the compiler can do > > without any help. > > The assembly calling functions need to know the compiler specific > > vtable and not a fixed self defined, which is not what I expected to see. > > It took me several days to understand that they want something senseless. > > Anyway, I seem to have fixed this. The build now passes this stage but > fails at another. The mozilla developers 'don't know' how to fix it, and > apparently lost the interest. > > Anybody here cares to comment? Something to do with incorrect alignment. Just accept the warnings. Mozilla also always had some missaligned acces in it. Fortunately we can correct missaligned access in userland and they are not too much so you can live with them. Especially since they said that the pointer always has the required alignment. The real bug is that they cast pointers of completely different types. You can work around by increasing the alignemnt requirement of PLDHashEntryHdr's type, so the compiler knows that. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From bugmaster at FreeBSD.org Mon Aug 18 11:06:46 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:07:03 2008 Subject: Current problem reports assigned to freebsd-alpha@FreeBSD.org Message-ID: <200808181106.m7IB6jGZ079724@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/61940 alpha [sysinstall] Can't disklabel new disk from FreeBSD/alp o alpha/61973 alpha Machine Check on boot-up of AlphaServer 2100A RM s alpha/67626 alpha X crashes an alpha machine, resulting reboot o alpha/85346 alpha PREEMPTION causes unstability in Alpha4000 SMP kernel o alpha/105134 alpha 'panic: lockmgr: thread ... not exclusive lock owner' 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/25284 alpha PC164 won't reboot with graphics console o alpha/38031 alpha osf1.ko not loaded during boot-time of linux-emu enabl o alpha/48676 alpha Changing the baud rate of serial consoles for Alpha sy o alpha/67903 alpha hw.chipset.memory: 1099511627776 - thats way to much : 4 problems total. From mexas at bristol.ac.uk Mon Aug 18 15:35:13 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Aug 18 15:35:20 2008 Subject: firefox3 build fails on alpha In-Reply-To: <20080818093918.GE6331@cicely7.cicely.de> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <20080816161820.GG37139@cicely7.cicely.de> <20080818083712.GA1032@mech-cluster238.men.bris.ac.uk> <20080818093918.GE6331@cicely7.cicely.de> Message-ID: <20080818153504.GA4848@mech-cluster238.men.bris.ac.uk> On Mon, Aug 18, 2008 at 11:39:18AM +0200, Bernd Walter wrote: > On Mon, Aug 18, 2008 at 09:37:12AM +0100, Anton Shterenlikht wrote: > > On Sat, Aug 16, 2008 at 06:18:20PM +0200, Bernd Walter wrote: > > > On Sat, Aug 02, 2008 at 05:01:23PM +0000, Christian Weisgerber wrote: > > > > Anton Shterenlikht wrote: > > > > > > > > > I'm happy to test firefox3 on alpha, but need to learn about pathes. > > > > > > > > > > In this particular case it seems that (at least) 2 files > > > > > are missing from the distribution: > > > > > > > > > > xptcinvoke_freebsd_alpha.cpp > > > > > xptcstubs_freebsd_alpha.cpp > > > > > > > > Yes. These need to be created. > > > > > > > > You have stumbled on a dirty secret: the Mozilla family programs > > > > rely on a part that must be ported at the assembly(!) language level > > > > to each processor/compiler/(operating system) combination. > > > > > > > > > I think that whoever created the tar file simply forgot to add the freebsd > > > > > files. > > > > > > > > No, somebody needs to write them. > > > > > > I wrote them a few years back for mozilla and they were part of the port. > > > Don't know what happened in the meantime, because since alpha support is > > > removed I stopped spending time into it. > > > The whole xptcinvoke thing is completely breandead anyway. > > > The intention was to have a portable interfacing to modules, but in fact > > > they just read the C++ vtable using assembly, which the compiler can do > > > without any help. > > > The assembly calling functions need to know the compiler specific > > > vtable and not a fixed self defined, which is not what I expected to see. > > > It took me several days to understand that they want something senseless. > > > > Anyway, I seem to have fixed this. The build now passes this stage but > > fails at another. The mozilla developers 'don't know' how to fix it, and > > apparently lost the interest. > > > > Anybody here cares to comment? Something to do with incorrect alignment. > > The real bug is that they cast pointers of completely different types. > You can work around by increasing the alignemnt requirement of > PLDHashEntryHdr's type, so the compiler knows that. Could you please elaborate on this? I see in pldhash.h: typedef PRUint32 PLDHashNumber; struct PLDHashEntryHdr { PLDHashNumber keyHash; /* every entry must begin like this */ }; I also see in ../../nsprpub/pr/include/prtypes.h /************************************************************************ ** TYPES: PRUint32 ** PRInt32 ** DESCRIPTION: ** The int32 types are known to be 32 bits each. ************************************************************************/ #if PR_BYTES_PER_INT == 4 typedef unsigned int PRUint32; typedef int PRInt32; #define PR_INT32(x) x #define PR_UINT32(x) x ## U #elif PR_BYTES_PER_LONG == 4 typedef unsigned long PRUint32; typedef long PRInt32; #define PR_INT32(x) x ## L #define PR_UINT32(x) x ## UL #else #error No suitable type for PRInt32/PRUint32 #endif but I cannot see where PR_BYTES_PER_xxx are defined. I think on alpha unsigned int should be 32 bit, it that correct? Shall I try to redefine PRUint32 to 32 bit for certain? thanks anton thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From freebsd at sopwith.solgatos.com Mon Aug 18 17:33:06 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Aug 18 17:33:13 2008 Subject: firefox3 build fails on alpha In-Reply-To: Your message of "Mon, 18 Aug 2008 16:35:04 BST." <20080818153504.GA4848@mech-cluster238.men.bris.ac.uk> Message-ID: <200808181731.RAA05832@sopwith.solgatos.com> > but I cannot see where PR_BYTES_PER_xxx are defined. find dir -name \*.h | xargs grep PR_BYTES_PER_ If that doesn't find it, leave out the -name \*.h > I think on alpha unsigned int should be 32 bit, it that correct? Should be. Easily verified: /* check_sizes.c * * Verify the size of various types. */ #include int main(int argc, char **argv) { printf("size of char = %ld\n", sizeof(char) ); printf("size of short = %ld\n", sizeof(short) ); printf("size of int = %ld\n", sizeof(int) ); printf("size of long = %ld\n", sizeof(long) ); printf("size of long long = %ld\n", sizeof(long long) ); printf("size of float = %ld\n", sizeof(float) ); printf("size of double = %ld\n", sizeof(double) ); return(0); } NetBSD/alpha and FreeBSD/amd64 both give: size of char = 1 size of short = 2 size of int = 4 size of long = 8 size of long long = 8 size of float = 4 size of double = 8 I would be very surprised if FreeBSD/alpha gives anything different. From mexas at bristol.ac.uk Tue Aug 19 15:58:44 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Tue Aug 19 15:58:51 2008 Subject: firefox build fails on alpha Message-ID: <20080819155839.GA27817@mech-cluster238.men.bris.ac.uk> On Mon, Aug 18, 2008 at 05:39:40PM +0000, freebsd@sopwith.solgatos.com wrote: > From: Dieter > > > but I cannot see where PR_BYTES_PER_xxx are defined. > > find dir -name \*.h | xargs grep PR_BYTES_PER_ well.. these are defined only in /usr/ports/www/firefox3/work/mozilla/nsprpub/pr/src/md/mac/prcpucfg.h that is for Mac, I think. But under unix this file doesn't appear: % cd /usr/ports/www/firefox3/work/mozilla/nsprpub/pr/src/md/ % ls Makefile.in mac prosdep.c windows beos os2 unix % % ls ./unix/*.h ls: No match. % I'm not sure what this means. > If that doesn't find it, leave out the -name \*.h > > > I think on alpha unsigned int should be 32 bit, it that correct? > > Should be. Easily verified: yes, int is 32 bit. Perhaps the problem is not in pldhash.h, but in nsCookieEntry: ../../../dist/include/xpcom/nsTHashtable.h: In static member function `static PRBool nsTHashtable::s_MatchEntry(PLDHashTable*, const PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]': ../../../dist/include/xpcom/nsTHashtable.h:334: instantiated from `PRBool nsTHashtable::Init(PRUint32) [with EntryType = nsCookieEntry]' nsCookieService.cpp:418: instantiated from here ../../../dist/include/xpcom/nsTHashtable.h:367: warning: cast from `const PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of target type I'm still not sure exactly what the 2 marked lines of code do: (extract from nsTHashtable.h) 361 template 362 PRBool 363 nsTHashtable::s_MatchEntry(PLDHashTable *table, 364 const PLDHashEntryHdr *entry, 365 const void *key) 366 { --> 367 return ((const EntryType*) entry)->KeyEquals( --> 368 static_cast(key)); 369 } but the error must be somewhere in these 2 lines, isn't it? anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From bugmaster at FreeBSD.org Mon Aug 25 11:06:46 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:07:10 2008 Subject: Current problem reports assigned to freebsd-alpha@FreeBSD.org Message-ID: <200808251106.m7PB6kDE027674@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/61940 alpha [sysinstall] Can't disklabel new disk from FreeBSD/alp o alpha/61973 alpha Machine Check on boot-up of AlphaServer 2100A RM s alpha/67626 alpha X crashes an alpha machine, resulting reboot o alpha/85346 alpha PREEMPTION causes unstability in Alpha4000 SMP kernel o alpha/105134 alpha 'panic: lockmgr: thread ... not exclusive lock owner' 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o alpha/25284 alpha PC164 won't reboot with graphics console o alpha/38031 alpha osf1.ko not loaded during boot-time of linux-emu enabl o alpha/48676 alpha Changing the baud rate of serial consoles for Alpha sy o alpha/67903 alpha hw.chipset.memory: 1099511627776 - thats way to much : 4 problems total. From peter at FreeBSD.org Mon Aug 25 04:17:01 2008 From: peter at FreeBSD.org (Peter Wemm) Date: Mon Aug 25 11:26:43 2008 Subject: Weekly 'p4 old-stuff summary' Message-ID: <200808250417.m7P4H09J056177@freefall.freebsd.org> Mon Aug 25 04:13:20 UTC 2008 http://people.freebsd.org/~peter/p4_cleanup.txt Add notes to //depot/doc/obliterate if you are having trouble deleting clients etc Changes stuck in *PENDING* state (please clean up!) 146596 2008/08/04 jb freebsd3 'Reset ' 145400 2008/07/18 alepulver alepulver_deimos '- Update README - Rem 138987 2008/03/30 piso piso_newluxor 'Let fragment pass. ' 138986 2008/03/30 piso piso_newluxor 'Let fragment pass. ' 135287 2008/02/13 obrien obrien_trang 'style.Makefile(5) ' 134956 2008/02/07 kmacy kmacy:storage:toehead '' 134505 2008/01/30 jb jb_freebsd1 'Remove calls to ddb. 134440 2008/01/30 jb jb_freebsd1 'IFdtrace //depot/pro 134400 2008/01/29 cognet kanar 'Use fixed size types. 128073 2007/10/25 eri eri 'IFC (hoping to build 127873 2007/10/21 attilio attilio_smp 'IFC ' 123651 2007/07/17 rink rink_pitchfork2 'Minor GCC 4.2 fixes - Users without clients for >1 month (not a problem, just FYI): 2003/11/12 kensmith 2005/11/08 green 2006/02/21 bmilekic 2006/07/15 harti 2006/07/18 pdeuskar 2006/09/21 jmelo 2007/03/08 r3boot 2007/04/17 kjayasurya 2007/04/17 clindsay 2007/06/19 dchu 2007/06/22 neelnatu 2007/06/24 linimon 2007/09/10 chris 2007/09/30 tobez 2007/10/14 ale 2007/10/26 lme 2007/10/26 miwi 2008/01/08 mckusick 2008/01/19 dunstan 2008/01/24 prasun 2008/02/19 hsahni 2008/02/19 bbeare 2008/02/21 vijay 2008/02/23 ryanb 2008/03/10 gibbs 2008/03/20 alex 2008/04/25 kmoore134 2008/04/26 danger 2008/05/01 aruns 2008/05/05 baz 2008/05/08 mtrujillo 2008/05/10 User 2008/05/19 ryan 2008/05/23 jaakko 2008/05/26 eric 2008/05/26 mneumann 2008/05/30 berber 2008/06/05 gary.tomic 2008/06/05 lichave 2008/06/05 versus 2008/06/09 njl 2008/06/10 aniket 2008/06/11 toshi 2008/06/23 miks 2008/06/28 frank 2008/07/08 fjoe 2008/07/09 evgenyzislis 2008/07/10 saper 2008/07/14 mdhall 2008/07/14 tmforce 2008/07/22 guest 2008/07/23 wpc 2008/07/24 ps Old clients (>6 months) without open files: 2004/04/11 silby silby_patrocles 2006/01/01 mat mat_bang 2006/01/25 jkim jkim_freefall 2006/01/30 glebius glebius_morannon 2006/01/31 glebius glebius_zoo 2006/02/01 pleblanc fbsd1 2006/02/02 pleblanc pleblanc_chart 2006/02/06 scottk linux 2006/02/07 scottk vaio 2006/02/07 pleblanc pleblanc_sefos1 2006/02/16 scottk 216.235.158.34 2006/02/17 scottk 68.217.74.108 2006/02/17 soc-yanjun yanjun 2006/02/17 deker deker_SEBSD_build.columbia.sparta.com 2006/02/22 deker deker_SEBSD_test.columbia.sparta.com 2006/02/23 areisse areisse_an 2006/02/23 deker deker_imac.slackdot.org 2006/02/24 arun arun-freebsd-xen3 2006/02/28 deker deker_build.slackdot.org 2006/03/02 johan johan_freefall 2006/03/09 soc-saturnero soc-saturnero_cristiana 2006/03/09 jpincus tardis 2006/03/09 scottk 210.213.197.144 2006/03/10 imp imp_ninjin 2006/03/14 tkuik tkuik_xen3 2006/03/17 scottk 210.213.197.25 2006/03/18 emaste emaste_laptop 2006/03/21 scottk hp 2006/03/21 deker korben 2006/03/22 kuriyama kuriyama_waterblue 2006/03/27 pleblanc pleblanc_korben 2006/04/03 deker sebsd_build_sparta 2006/04/22 scottk pavilion 2006/05/14 mat mat_atuin 2006/05/19 philip philip_freefall 2006/05/27 rdivacky witten 2006/05/28 soc-cjones soc-cjones_ides 2006/05/29 perforce perforce_repoman 2006/05/29 kevlo view 2006/05/29 yuanjue yuanjue 2006/05/30 markm markm_greatest_current 2006/05/30 clem1 pouik 2006/05/31 alouca alouca_laptop 2006/05/31 swhitman JOECATMINI 2006/05/31 rodrigc rodrigc_dibbler 2006/06/05 marcio marcio 2006/06/07 deker deker_sparta 2006/06/07 deker deker 2006/06/08 swhitman trillian 2006/06/10 tyler tyler_l4bsd 2006/06/11 hugo hugo_server2.meiland.nl 2006/06/15 trhodes trhodes 2006/06/17 lawrance gis2 2006/06/19 m coffee 2006/06/21 samy seascf-999lv81 2006/06/21 pleblanc pleblanc_p4 2006/06/23 cdjones igneous 2006/06/25 cdjones impulse 2006/06/25 joel joel_dude 2006/06/26 m m_coffee 2006/06/27 piso piso_asuka 2006/06/27 adamartin adamartin-tethys 2006/06/30 grehan grehan_xen 2006/07/03 ume ume_cheer 2006/07/03 clsung cls_freefall 2006/07/06 deker sebsd_build 2006/07/12 trhodes trhodes-x64 2006/07/15 bmah bmah_laptop 2006/07/17 millert millert_ibook 2006/07/23 luoqi luoqi-ltvm 2006/07/25 kuriyama kuriyama_sienna_ref54 2006/07/25 kuriyama kuriyama_sienna_ref53 2006/07/31 kmacy kmacy_storage:sun4v_dtrace 2006/08/01 clem1 clem1_ipv6vulns 2006/08/04 jvalko jvalko_testbox 2006/08/10 ticso ticso-cicely5 2006/08/11 scottk pcbsd 2006/08/16 dongmei soc-dongmei-trustedbsd 2006/08/19 swhitman swhitman_joethecat 2006/08/22 dongmei soc-dongmei-freebsd 2006/08/25 glebius glebius_behemoth 2006/08/26 shteryana sht-work_snmp 2006/08/27 yuanjue maver-freebsd 2006/08/27 piso piso_gaia 2006/08/27 rik rik_hanum 2006/08/28 ume ume_kasuga 2006/08/29 cdjones cdjones_meanook 2006/08/30 tkuik tkuik_freebsd 2006/09/05 swhitman swhitman_joecatmini 2006/09/06 tyler powerbook_audit 2006/09/13 alc alc_rice 2006/09/22 jvalko thor 2006/09/26 m m_jana 2006/10/10 attilio attilio_laptop 2006/10/11 piso piso_behemoth 2006/10/14 piso piso_jujik 2006/10/25 kevlo kevlo_cens 2006/10/27 deker deker_build1.columbia.sparta.com 2006/10/28 ahze ahze_blueherron 2006/11/08 kmacy kmacy_storage:sun4v_work_current 2006/11/08 kmacy kmacy_storage:sun4v_work_stable 2006/11/09 kmacy kmacy_storage:sun4v_work_devel 2006/11/10 scottk server 2006/11/11 maxim maxim_sonnie 2006/11/12 ru ru_edoofus 2006/11/16 jkim info 2006/11/20 iedowse iedowse_nothing 2006/11/21 kevlo kevlo_monet 2006/11/21 soc-saturnero soc-saturnero_marvin 2006/11/22 marius marius_futile 2006/11/22 emaste emaste_sv_superpages 2006/11/22 emaste bsd-build3 2006/11/25 ssouhlal ssouhlal-maho 2006/11/30 jaras jaras_pacomp 2006/11/30 jaras jarek_v6 2006/12/06 jaras jares_compiler 2006/12/13 jaras jaras_v6 2006/12/15 piso piso_zoo 2006/12/17 ahze blueherron 2006/12/18 mux pentane 2006/12/26 tyler powerbook 2006/12/31 kmacy 75.37.93.18 2007/01/07 riddick neo.riddick.homeunix.org. 2007/01/08 grehan arm_dev 2007/01/09 dodell dho 2007/01/10 kmacy netherworld 2007/01/16 csjp csjp_cell0 2007/01/19 lsc lsc_loomis 2007/01/30 piso newluxor 2007/02/08 chibis chibis_atwork 2007/02/20 dumbbell dumbbell_magellan 2007/02/21 millert millert_p4 2007/02/23 millert millert_g5tower 2007/02/23 millert millert_g4tower 2007/02/24 jeff jeff_laptop0 2007/02/26 millert millert_macbook 2007/02/28 cognet cognet 2007/02/28 millert millert_g4dual 2007/03/03 wkoszek wkoszek_dunstan 2007/03/05 dongmei soc-dongmei-sebsd 2007/03/06 syrinx zeus 2007/03/08 flz flz_innercity 2007/03/09 piso piso_longino 2007/03/12 csjp csjp_rnd01 2007/03/13 millert millert_p3 2007/03/27 cdjones cdjones_ides 2007/03/30 nsouch localhost 2007/03/31 tyler intellian_audit 2007/04/01 samarunraj samarunraj_elfwork 2007/04/13 netchild netchild_magellan 2007/04/14 ups ups_build 2007/04/15 samarunraj samarunraj_vm 2007/04/16 jhb jhb_zoo 2007/04/17 scottl scottl-wv1u 2007/04/18 ambrisko a21p 2007/04/18 des des.at.zoo.freebsd.org 2007/04/19 grehan mips2_dev 2007/04/23 jpincus jpincus_storage:sun4v_work 2007/04/24 sorbo sorbo_laptop 2007/04/30 mjacob mj-scottl 2007/05/09 soc-yanjun Earth 2007/05/19 adamartin adamartin_hobbesxx 2007/05/19 csjp csjp_push 2007/05/19 ivoras ivoras_beastie 2007/05/24 marks marks_par_current 2007/05/25 kmacy kmacy_storage:opentoe_work 2007/05/28 kmacy vt-x 2007/05/31 will will_phobos 2007/06/05 amigus amigus_laptop 2007/06/05 jvalko jvalko_thor 2007/06/11 nsouch piso_skytech 2007/06/12 cdjones cdjones_iconoclast 2007/06/12 dongmei soc2007zhouzhouyi 2007/06/16 maxim maxim_fujic 2007/06/17 krion krion_voodoo 2007/06/18 eri eri-dev 2007/06/22 chub mu 2007/06/24 zhouzhouyi lulf 2007/06/25 mjacob mjexp_sparc64 2007/06/28 kmacy serendipity:opentoe_togo 2007/07/01 chub chub-freebsd 2007/07/03 rink vian 2007/07/03 lulf lulf_ridcully 2007/07/04 philip philip_fasolt 2007/07/05 chub freebsd-perforce 2007/07/12 kmacy parmacvm:opentoe_parvm 2007/07/13 mprevot mprevot_freebsd64 2007/07/13 mprevot scienceclue 2007/07/13 mprevot mprevot_fbsd64 2007/07/15 ivoras ivoras_vsdev 2007/07/22 ogould isla 2007/07/24 gordon gordon_mugu 2007/07/29 mjacob mjexp-obrien 2007/07/31 attilio attilio_xen 2007/08/02 zhouzhouyi zhouzhouyi_incksum 2007/08/02 ivoras ivoras_beastie2 2007/08/06 marcus marcus_shumai 2007/08/06 kmacy kmacy:freefall_ethng 2007/08/09 jbr jbr_faust 2007/08/10 cognet work 2007/08/14 emaste laptop 2007/08/17 jkim jkim_hammer 2007/08/19 smilicic tanarri_marilith 2007/08/20 fabio fabio_gror 2007/08/21 chibis chibis_free 2007/08/22 peter peter_cheese 2007/08/24 jbr jbr_bob 2007/08/24 anchie malimis 2007/08/25 sam sam_aku 2007/08/25 emaste emaste_soc_laptop 2007/08/27 peter peter_vbsd1 2007/08/29 simokawa simokawa_tank 2007/08/31 lulf lulf_rincewind 2007/09/01 yar yar_jujik 2007/09/04 rwatson rwatson_coverity 2007/09/05 kmacy kmacy_freefall:toestack 2007/09/07 ljian pony 2007/09/07 loafier chrisdsoc 2007/09/10 ljian pony2 2007/09/10 le le_korben 2007/09/10 mharvan mharvan_bike-planet 2007/09/11 tol tol_hippo 2007/09/12 cnst last 2007/09/18 kmacy kip-macys-computer:opentoe_mbpro 2007/09/19 kevlo kevlo_nsl 2007/09/19 ceri ceri_fenrir 2007/09/21 zhouzhouyi zhouzhouyi-camlock 2007/09/21 ceri ceri_shrike2 2007/09/21 ceri ceri_shrike 2007/09/24 delphij delphij_freefall 2007/09/25 ceri ceri_quinch 2007/09/25 adamartin adamartin_fsl 2007/09/25 adamartin autofs_fsl 2007/09/25 adamartin autofs_hobbes 2007/09/26 ceri ceri_peasant 2007/09/27 delphij delphij_odin 2007/09/28 arved arved_mchammer 2007/09/28 matteo matteo_kaiser_rpc 2007/09/29 wwesolowsky MOOCHIE 2007/09/29 hselasky hselasky_mini_itx 2007/10/03 jhb t-o 2007/10/03 jhb jhb_freefall 2007/10/07 fli fli_manticore 2007/10/12 ssouhlal ssouhlal_w18 2007/10/12 brooks brooks_fellowship 2007/10/12 cnst dale 2007/10/13 yar yar_dg6 2007/10/14 thioretic thioretic_freebox 2007/10/15 ljian thinkpad 2007/10/18 peter peter_hammer 2007/10/19 bushman soc-bushman 2007/10/19 bushman bushman_sh 2007/10/22 kmacy freefall_kmacy_xen31 2007/10/24 csjp push 2007/10/25 gordon gordon_mini 2007/10/25 lulf gvinum_convert 2007/10/26 gordon gordon_allie 2007/10/27 mlaier mlaier_flux 2007/11/01 weongyo weongyo_wifi 2007/11/01 swise swise:vic10:toestack 2007/11/02 gallatin whisper 2007/11/02 grehan excfreebsd 2007/11/05 gallatin whisper_zcopybpf 2007/11/07 peter peter_work 2007/11/07 kris kris_e4500 2007/11/09 gordon review_p4repl_rebuild 2007/11/19 zhouzhouyi zzy 2007/11/20 jaras jaras_compiler 2007/11/21 yar yar_behemoth 2007/11/23 gcooper optimus-pkg_revised 2007/11/24 rrs stewlap-rrs-exp 2007/11/24 kmacy kmacy:zoo:ethng 2007/11/29 ivoras ivoras_finstall 2007/11/29 ivoras ivoras_gv7 2007/12/03 kmacy kmacy:entropy:vendor_old 2007/12/04 julian julian_jules1 2007/12/05 kmacy freefall_kmacy_iwarp 2007/12/12 kmacy kmacy:entropy:toehead 2007/12/12 kmacy kmacy:entropy:toestack 2007/12/12 kmacy kmacy:freefall:toehead 2007/12/12 kmacy kmacy:freefall:toestack 2007/12/12 rrs rrs-dtrace7 2007/12/12 rrs gcc-cavium 2007/12/12 rrs mips2-rrs 2007/12/13 gordon gordon_mbp 2007/12/14 njli li_tirts 2007/12/15 stas stas_phonon 2007/12/15 ssouhlal ssouhlal_bleh 2007/12/16 njli tirts 2007/12/20 jhealy jhealy_gaz 2007/12/20 grehan grehan:iwarp 2007/12/22 xpenguin help 2007/12/22 lstewart newbox 2007/12/29 peter peter_repocopy 2008/01/05 kib kib_deviant_alc 2008/01/06 imp imp_quato 2008/01/07 adrian wendy 2008/01/08 imp imp_nova-bsd-build1 2008/01/09 ambrisko z61p 2008/01/13 sephe sephe_zealot:vap 2008/01/15 grehan grehan:e500 2008/01/15 jhealy jhealy_newbox 2008/01/16 benno benno_kate 2008/01/17 rrs mips_cavium_rrs 2008/01/19 kris kris_eth 2008/01/19 peter peter_freefall 2008/01/20 scottl scottl-ix 2008/01/20 maxim maxim_mp2 2008/01/21 gonzo gonzo_laptop 2008/01/21 gonzo gonzo_wooster 2008/01/23 adrian adrian_jacinta 2008/01/23 adrian jacinta 2008/01/23 rrs rrs-altroute 2008/01/25 scottk z61m 2008/01/26 jgo greg-thinkpad 2008/01/26 jgo jgo_i386 2008/01/29 rrs stewlap 2008/01/30 kmacy entropy_kmacy_xen31 2008/01/31 kmacy kmacy_home:ethng 2008/02/02 mharvan mharvan_styx 2008/02/05 rwatson rwatson_pinata 2008/02/05 rrs rrs-dtrace8 2008/02/09 yar yar_dg 2008/02/11 benno benno_vtbsd 2008/02/11 rrs rrs-mips2-jnpr-2 2008/02/12 lstewart lstewart_caiavm 2008/02/12 benjsc benjsc_wolf 2008/02/12 pwood pwood_caesium 2008/02/13 erwin erwin_aphrodite 2008/02/14 anderson neutrino 2008/02/14 cognet hulglah 2008/02/17 csjp csjp_ibm01 2008/02/18 stekloff dsteklof-FreeBSD 2008/02/18 jmallett jmallett_toxic 2008/02/18 eri altq 2008/02/23 lwhsu lucky7 2008/02/25 dongmei DONGMEI 2008/02/25 scottk xen 2008/02/25 scottk scottk_trustedbsd 2008/02/26 taleks taleks_th 2008/02/26 jeff desktop Old clients (>1 month) with open files (sorted by date): 2003/12/14 24 jake jake_k7 2004/02/15 5 emoe emoe_s390_intelli 2004/03/09 12 emoe emoe_s390 2004/03/24 3 tjr tjr_vm 2004/04/08 5 areisse areisse_g4 2004/04/16 1 mini mini_shim 2004/07/09 1 simokawa simokawa_tora2 2004/09/20 19 tjr tjr_dev 2004/11/19 3 simokawa simokawa_ett 2004/12/08 2 pjd_ro pjd_czort 2004/12/17 1 arr arr_hfs 2004/12/19 1 tjr tjr_yuiop 2005/01/17 1 gnagelhout GNAGELHOUT-PC3 2005/02/27 1 phantom phantom_eagle 2005/03/04 51 bigbrother anton-apple 2005/05/22 1 peter peter_hub 2005/06/13 4313 ups ups_palm 2005/07/06 3767 mdodd mdodd_ms6167 2005/07/13 1 rwatson rwatson_nutmeg 2005/07/15 1 dd dd_beaver 2005/07/28 7 areisse areisse_ibook 2005/08/04 4 deker oxide 2005/10/03 11 soc-emily soc-emily_beastie 2005/10/04 9 crameri crameri_labospc40 2005/10/05 5 kelly kelly_riveroaks2.earthlink.net 2005/10/19 2 imp imp_hondo 2005/11/15 4 dd dd_maverick 2005/12/25 1 nork nork_pelsia 2006/01/08 1 soc-polytopes polytopes_kafka 2006/02/03 1 roam roam_straylight 2006/02/04 1 alc alc_sp01 2006/03/16 1 philip philip_loge 2006/04/05 28 kmacy kmacy_storage:sun4vtmp 2006/04/11 3 pjd pjd_slayer 2006/04/24 10 kmacy jmg_kmacy 2006/05/09 148 marks marks_laptop 2006/05/29 1 soc-bushman soc-bushman_stinger 2006/06/01 10 kmacy kmacy_storage:sun4v_rwbuf 2006/06/11 5820 dongmei soc-dongmei-xp 2006/06/13 14 rwatson rwatson_paprika 2006/06/16 6 dongmei dongmei-test-client 2006/06/21 37 kmacy kmacy_storage:sun4v_work 2006/06/25 9 kmacy kmacy_storage:sun4v_work_ifc 2006/06/30 10 kmacy kmacy_storage:sun4v_work_sleepq 2006/06/30 15 kmacy kmacy_storage:sun4v_work_test 2006/07/06 2 imp imp_Speedy 2006/07/07 1 lawrance dirk 2006/07/09 1552 anholt anholt_leguin 2006/07/30 4 kmacy kmacy_vt-x:dtrace 2006/07/31 8 kmacy kmacy_storage:sun4v_work_experimental_sux 2006/08/21 1 cdjones cdjones-impulse 2006/08/29 36 cdjones cdjones_igneous 2006/09/04 9 ssouhlal ssouhlal-warp9 2006/09/09 7 davidxu davidxu_alona 2006/09/17 5 gnn gnn_devbox_fast_ipsec 2006/09/27 3 pjd pjd_lcf 2006/09/27 4 dodell the-bofh 2006/10/26 34504 samy samy_viva 2006/10/28 4 kmacy kmacy:freebsd7_xen3 2006/11/09 2307 kmacy kmacy_storage:xen_work_current 2006/11/24 5 mdodd mdodd_ibmtp600e 2006/12/05 10 kmacy kmacy_storage:sun4v_pmap_corruption 2006/12/16 5 alc alc_office 2006/12/29 61 kmacy kmacy_storage:sun4v_work_superpages 2007/01/01 3 kmacy kmacy_storage:kmacy_wifi 2007/01/14 4 kmacy kmacy_storage:sam_wifi 2007/01/19 4 kmacy kmacy_vt-x:usb 2007/01/19 10 nsouch nsouch_armor 2007/01/21 2 tyler orange 2007/01/22 1 kmacy kmacy_netherworld:sam_wifi 2007/01/26 42675 lsc loomis 2007/02/19 31599 simokawa simokawa_tora 2007/02/23 3 dumbbell dumbbell_viking 2007/02/27 1 bushman bushman_nss_ldap_cached 2007/03/30 8 dwhite dwhite_stan 2007/03/30 35439 nsouch hglee_darkstar 2007/04/15 5 als als_head 2007/05/13 15 kmacy kmacy_serendipity:sam_wifi 2007/05/17 2 mlaier mlaier_testlap 2007/06/12 2 dongmei soc2007 2007/06/17 6156 rink rink_pitchfork 2007/06/22 3068 marks marks_macbook 2007/06/29 43 chub chub-soc2007 2007/07/02 6 eri eri_dev 2007/07/03 34 peter peter_ia64 2007/07/06 3 kmacy kmacy_vt-x:opentoe_init 2007/07/20 4 ups ups_giant 2007/07/27 1 chub chub-perforce-mu 2007/07/27 63 chub chub-msdosfs 2007/07/29 42 alfred alfred_parallel 2007/08/06 37342 kmacy kmacy_storage:ethng 2007/09/07 16 gcooper optimus-revised_pkgtools 2007/09/16 1 karma karma_ez 2007/09/19 2 dds dds_hawk 2007/09/21 40895 kmacy storage 2007/09/25 2 adamartin adamartin_hobbes 2007/10/08 4 imp imp_marvin 2007/10/21 3 kmacy kmacy_home:ethng_ref 2007/10/29 5 rink rink_pitchfork2 2007/11/04 4 gordon gordon_bally 2007/11/05 767 attilio attilio_smp 2007/11/05 1 gordon gordon_repoman 2007/11/06 13 kmacy kmacy_home:opentoe 2007/12/19 7 kmacy kmacy:storage:toestack 2007/12/28 13 ticso ticso 2008/01/01 1 kmacy entropy_kmacy_xen3 2008/01/17 136 gcooper shiina-ibook 2008/01/18 1 kris kris_gumby2a 2008/01/19 1 wkoszek wkoszek_sledge 2008/01/21 30 trhodes trhodes_local 2008/01/21 1 rwatson rwatson_cinnamon_netisr2 2008/01/22 2 benno benno_windfarm 2008/01/22 1 rrs mips_rrs 2008/02/01 25734 kevlo kevlo_rtsl 2008/02/07 1 pramod pramod_linux 2008/02/14 2 cognet cognet-mips 2008/02/16 168 eri eri 2008/02/17 2 kris kris_gumby5 2008/02/18 4 csjp csjp_xor 2008/02/21 60 kris kris_zoo_net 2008/02/23 5 kmacy kmacy:storage:toehead 2008/02/26 29 kris kris_16core 2008/02/29 22 kmacy pandemonium:kmacy:xen31_6 2008/03/01 138 cperciva cperciva_freefall 2008/03/08 1 delphij tarsier 2008/03/09 5 kmacy kmacy:entropy:iwarp 2008/03/12 1 phk phk_hex 2008/03/13 2 kris kris_barc1 2008/03/17 7384 kmacy pandemonium:kmacy:iwarp 2008/03/20 1 swise swise:vic10:iwarp 2008/03/21 4 jb jb_freebsd8 2008/03/26 8 gnn gnn_nozomi8 2008/04/01 2 scottl scottl-deimos 2008/04/02 1 gordon gordon_charlie 2008/04/11 5 rrs rrs-mips2-jnpr 2008/04/14 19 rwatson rwatson_zoo 2008/04/19 1 peter peter_melody 2008/04/19 3 rwatson rwatson_noisy 2008/04/19 2 rwatson rwatson_noisier 2008/04/22 45 fli fli_genesis 2008/04/24 1 sat sat_amilo 2008/04/27 1 brueffer brueffer_serenity 2008/04/29 2 mlaier mlaier_amd64 2008/05/01 2535 ups ups_tinto 2008/05/01 7 peter peter_macbook 2008/05/02 9 jls jls_whack 2008/05/04 2238 carvay terry 2008/05/13 1 wwesolowsky wadew-ports 2008/05/21 3 murray murray_hilbert_django 2008/05/23 6299 rink rink_vian 2008/05/25 6 phk phk_critter 2008/05/27 1 gordon gordon_rootbsd 2008/05/28 5 gnn gnn_builder 2008/06/03 1 grehan grehan-mips2 2008/06/08 3147 wkoszek wkoszek_laptop 2008/06/11 3 gnn gnn_laptop_fbsd64 2008/06/20 25 kris kris_zoo_superpages 2008/06/20 34 kris kris_zoo_rwatson_udp 2008/06/21 8 kris kris_zoo6 2008/07/07 996 lqlee fbsd 2008/07/07 7 andre andre_flirtbox 2008/07/09 2 brooks brooks_lor 2008/07/12 1 kris kris_zoo_vimage 2008/07/13 455 attilio attilio_sched_lock 2008/07/14 99 kris kris_pointyhat 2008/07/19 115 kris kris_zoo1 2008/07/21 22 kris kris_zoo_tty 2008/07/23 7 rdivacky rdivacky_witten Old clients (>1 month) with open files (sorted by files): 2007/01/26 42675 lsc loomis 2007/09/21 40895 kmacy storage 2007/08/06 37342 kmacy kmacy_storage:ethng 2007/03/30 35439 nsouch hglee_darkstar 2006/10/26 34504 samy samy_viva 2007/02/19 31599 simokawa simokawa_tora 2008/02/01 25734 kevlo kevlo_rtsl 2008/03/17 7384 kmacy pandemonium:kmacy:iwarp 2008/05/23 6299 rink rink_vian 2007/06/17 6156 rink rink_pitchfork 2006/06/11 5820 dongmei soc-dongmei-xp 2005/06/13 4313 ups ups_palm 2005/07/06 3767 mdodd mdodd_ms6167 2008/06/08 3147 wkoszek wkoszek_laptop 2007/06/22 3068 marks marks_macbook 2008/05/01 2535 ups ups_tinto 2006/11/09 2307 kmacy kmacy_storage:xen_work_current 2008/05/04 2238 carvay terry 2006/07/09 1552 anholt anholt_leguin 2008/07/07 996 lqlee fbsd 2007/11/05 767 attilio attilio_smp 2008/07/13 455 attilio attilio_sched_lock 2008/02/16 168 eri eri 2006/05/09 148 marks marks_laptop 2008/03/01 138 cperciva cperciva_freefall 2008/01/17 136 gcooper shiina-ibook 2008/07/19 115 kris kris_zoo1 2008/07/14 99 kris kris_pointyhat 2007/07/27 63 chub chub-msdosfs 2006/12/29 61 kmacy kmacy_storage:sun4v_work_superpages 2008/02/21 60 kris kris_zoo_net 2005/03/04 51 bigbrother anton-apple 2008/04/22 45 fli fli_genesis 2007/06/29 43 chub chub-soc2007 2007/07/29 42 alfred alfred_parallel 2006/06/21 37 kmacy kmacy_storage:sun4v_work 2006/08/29 36 cdjones cdjones_igneous 2008/06/20 34 kris kris_zoo_rwatson_udp 2007/07/03 34 peter peter_ia64 2008/01/21 30 trhodes trhodes_local 2008/02/26 29 kris kris_16core 2006/04/05 28 kmacy kmacy_storage:sun4vtmp 2008/06/20 25 kris kris_zoo_superpages 2003/12/14 24 jake jake_k7 2008/07/21 22 kris kris_zoo_tty 2008/02/29 22 kmacy pandemonium:kmacy:xen31_6 2008/04/14 19 rwatson rwatson_zoo 2004/09/20 19 tjr tjr_dev 2007/09/07 16 gcooper optimus-revised_pkgtools 2006/06/30 15 kmacy kmacy_storage:sun4v_work_test 2007/05/13 15 kmacy kmacy_serendipity:sam_wifi 2006/06/13 14 rwatson rwatson_paprika 2007/12/28 13 ticso ticso 2007/11/06 13 kmacy kmacy_home:opentoe 2004/03/09 12 emoe emoe_s390 2005/10/03 11 soc-emily soc-emily_beastie 2006/06/30 10 kmacy kmacy_storage:sun4v_work_sleepq 2006/04/24 10 kmacy jmg_kmacy 2006/06/01 10 kmacy kmacy_storage:sun4v_rwbuf 2006/12/05 10 kmacy kmacy_storage:sun4v_pmap_corruption 2007/01/19 10 nsouch nsouch_armor 2006/06/25 9 kmacy kmacy_storage:sun4v_work_ifc 2006/09/04 9 ssouhlal ssouhlal-warp9 2008/05/02 9 jls jls_whack 2005/10/04 9 crameri crameri_labospc40 2007/03/30 8 dwhite dwhite_stan 2008/03/26 8 gnn gnn_nozomi8 2008/06/21 8 kris kris_zoo6 2006/07/31 8 kmacy kmacy_storage:sun4v_work_experimental_sux 2006/09/09 7 davidxu davidxu_alona 2005/07/28 7 areisse areisse_ibook 2008/05/01 7 peter peter_macbook 2007/12/19 7 kmacy kmacy:storage:toestack 2008/07/23 7 rdivacky rdivacky_witten 2008/07/07 7 andre andre_flirtbox 2008/05/25 6 phk phk_critter 2007/07/02 6 eri eri_dev 2006/06/16 6 dongmei dongmei-test-client 2006/11/24 5 mdodd mdodd_ibmtp600e 2008/03/09 5 kmacy kmacy:entropy:iwarp 2004/02/15 5 emoe emoe_s390_intelli 2007/04/15 5 als als_head 2006/09/17 5 gnn gnn_devbox_fast_ipsec 2007/10/29 5 rink rink_pitchfork2 2004/04/08 5 areisse areisse_g4 2008/05/28 5 gnn gnn_builder 2008/04/11 5 rrs rrs-mips2-jnpr 2006/12/16 5 alc alc_office 2008/02/23 5 kmacy kmacy:storage:toehead 2005/10/05 5 kelly kelly_riveroaks2.earthlink.net 2007/01/19 4 kmacy kmacy_vt-x:usb 2007/11/04 4 gordon gordon_bally 2007/10/08 4 imp imp_marvin 2006/10/28 4 kmacy kmacy:freebsd7_xen3 2006/09/27 4 dodell the-bofh 2006/07/30 4 kmacy kmacy_vt-x:dtrace 2005/11/15 4 dd dd_maverick 2008/03/21 4 jb jb_freebsd8 2007/01/14 4 kmacy kmacy_storage:sam_wifi 2005/08/04 4 deker oxide 2007/07/20 4 ups ups_giant 2008/02/18 4 csjp csjp_xor 2007/07/06 3 kmacy kmacy_vt-x:opentoe_init 2006/09/27 3 pjd pjd_lcf 2008/05/21 3 murray murray_hilbert_django 2006/04/11 3 pjd pjd_slayer 2007/02/23 3 dumbbell dumbbell_viking 2007/01/01 3 kmacy kmacy_storage:kmacy_wifi 2004/03/24 3 tjr tjr_vm 2004/11/19 3 simokawa simokawa_ett 2008/06/11 3 gnn gnn_laptop_fbsd64 2008/04/19 3 rwatson rwatson_noisy 2007/10/21 3 kmacy kmacy_home:ethng_ref 2007/01/21 2 tyler orange 2008/02/14 2 cognet cognet-mips 2007/09/19 2 dds dds_hawk 2008/01/22 2 benno benno_windfarm 2008/07/09 2 brooks brooks_lor 2008/04/19 2 rwatson rwatson_noisier 2005/10/19 2 imp imp_hondo 2006/07/06 2 imp imp_Speedy 2008/03/13 2 kris kris_barc1 2007/05/17 2 mlaier mlaier_testlap 2007/06/12 2 dongmei soc2007 2004/12/08 2 pjd_ro pjd_czort 2008/02/17 2 kris kris_gumby5 2008/04/01 2 scottl scottl-deimos 2008/04/29 2 mlaier mlaier_amd64 2007/09/25 2 adamartin adamartin_hobbes 2005/07/13 1 rwatson rwatson_nutmeg 2004/12/19 1 tjr tjr_yuiop 2008/04/02 1 gordon gordon_charlie 2008/03/08 1 delphij tarsier 2005/07/15 1 dd dd_beaver 2007/01/22 1 kmacy kmacy_netherworld:sam_wifi 2008/04/19 1 peter peter_melody 2008/01/19 1 wkoszek wkoszek_sledge 2007/09/16 1 karma karma_ez 2007/11/05 1 gordon gordon_repoman 2008/03/12 1 phk phk_hex 2008/04/27 1 brueffer brueffer_serenity 2008/04/24 1 sat sat_amilo 2005/12/25 1 nork nork_pelsia 2008/05/13 1 wwesolowsky wadew-ports 2008/01/21 1 rwatson rwatson_cinnamon_netisr2 2006/02/03 1 roam roam_straylight 2008/01/22 1 rrs mips_rrs 2006/02/04 1 alc alc_sp01 2008/01/01 1 kmacy entropy_kmacy_xen3 2007/02/27 1 bushman bushman_nss_ldap_cached 2008/05/27 1 gordon gordon_rootbsd 2004/07/09 1 simokawa simokawa_tora2 2007/07/27 1 chub chub-perforce-mu 2005/05/22 1 peter peter_hub 2008/01/18 1 kris kris_gumby2a 2006/01/08 1 soc-polytopes polytopes_kafka 2005/01/17 1 gnagelhout GNAGELHOUT-PC3 2006/05/29 1 soc-bushman soc-bushman_stinger 2005/02/27 1 phantom phantom_eagle 2008/02/07 1 pramod pramod_linux 2006/07/07 1 lawrance dirk 2004/12/17 1 arr arr_hfs 2008/07/12 1 kris kris_zoo_vimage 2004/04/16 1 mini mini_shim 2006/08/21 1 cdjones cdjones-impulse 2006/03/16 1 philip philip_loge 2008/06/03 1 grehan grehan-mips2 2008/03/20 1 swise swise:vic10:iwarp Old clients (>1 month) with open files (sorted by user): 2007/09/25 2 adamartin adamartin_hobbes 2006/02/04 1 alc alc_sp01 2006/12/16 5 alc alc_office 2007/07/29 42 alfred alfred_parallel 2007/04/15 5 als als_head 2008/07/07 7 andre andre_flirtbox 2006/07/09 1552 anholt anholt_leguin 2005/07/28 7 areisse areisse_ibook 2004/04/08 5 areisse areisse_g4 2004/12/17 1 arr arr_hfs 2008/07/13 455 attilio attilio_sched_lock 2007/11/05 767 attilio attilio_smp 2008/01/22 2 benno benno_windfarm 2005/03/04 51 bigbrother anton-apple 2008/07/09 2 brooks brooks_lor 2008/04/27 1 brueffer brueffer_serenity 2007/02/27 1 bushman bushman_nss_ldap_cached 2008/05/04 2238 carvay terry 2006/08/29 36 cdjones cdjones_igneous 2006/08/21 1 cdjones cdjones-impulse 2007/06/29 43 chub chub-soc2007 2007/07/27 63 chub chub-msdosfs 2007/07/27 1 chub chub-perforce-mu 2008/02/14 2 cognet cognet-mips 2008/03/01 138 cperciva cperciva_freefall 2005/10/04 9 crameri crameri_labospc40 2008/02/18 4 csjp csjp_xor 2006/09/09 7 davidxu davidxu_alona 2005/07/15 1 dd dd_beaver 2005/11/15 4 dd dd_maverick 2007/09/19 2 dds dds_hawk 2005/08/04 4 deker oxide 2008/03/08 1 delphij tarsier 2006/09/27 4 dodell the-bofh 2006/06/11 5820 dongmei soc-dongmei-xp 2007/06/12 2 dongmei soc2007 2006/06/16 6 dongmei dongmei-test-client 2007/02/23 3 dumbbell dumbbell_viking 2007/03/30 8 dwhite dwhite_stan 2004/02/15 5 emoe emoe_s390_intelli 2004/03/09 12 emoe emoe_s390 2007/07/02 6 eri eri_dev 2008/02/16 168 eri eri 2008/04/22 45 fli fli_genesis 2007/09/07 16 gcooper optimus-revised_pkgtools 2008/01/17 136 gcooper shiina-ibook 2005/01/17 1 gnagelhout GNAGELHOUT-PC3 2006/09/17 5 gnn gnn_devbox_fast_ipsec 2008/05/28 5 gnn gnn_builder 2008/03/26 8 gnn gnn_nozomi8 2008/06/11 3 gnn gnn_laptop_fbsd64 2008/04/02 1 gordon gordon_charlie 2007/11/04 4 gordon gordon_bally 2007/11/05 1 gordon gordon_repoman 2008/05/27 1 gordon gordon_rootbsd 2008/06/03 1 grehan grehan-mips2 2007/10/08 4 imp imp_marvin 2005/10/19 2 imp imp_hondo 2006/07/06 2 imp imp_Speedy 2003/12/14 24 jake jake_k7 2008/03/21 4 jb jb_freebsd8 2008/05/02 9 jls jls_whack 2007/09/16 1 karma karma_ez 2005/10/05 5 kelly kelly_riveroaks2.earthlink.net 2008/02/01 25734 kevlo kevlo_rtsl 2007/01/19 4 kmacy kmacy_vt-x:usb 2008/03/09 5 kmacy kmacy:entropy:iwarp 2006/06/30 10 kmacy kmacy_storage:sun4v_work_sleepq 2007/07/06 3 kmacy kmacy_vt-x:opentoe_init 2006/06/25 9 kmacy kmacy_storage:sun4v_work_ifc 2007/09/21 40895 kmacy storage 2007/12/19 7 kmacy kmacy:storage:toestack 2006/10/28 4 kmacy kmacy:freebsd7_xen3 2006/04/24 10 kmacy jmg_kmacy 2007/01/22 1 kmacy kmacy_netherworld:sam_wifi 2008/03/17 7384 kmacy pandemonium:kmacy:iwarp 2006/06/01 10 kmacy kmacy_storage:sun4v_rwbuf 2007/11/06 13 kmacy kmacy_home:opentoe 2007/08/06 37342 kmacy kmacy_storage:ethng 2006/07/30 4 kmacy kmacy_vt-x:dtrace 2007/01/01 3 kmacy kmacy_storage:kmacy_wifi 2006/06/21 37 kmacy kmacy_storage:sun4v_work 2008/02/29 22 kmacy pandemonium:kmacy:xen31_6 2008/01/01 1 kmacy entropy_kmacy_xen3 2006/06/30 15 kmacy kmacy_storage:sun4v_work_test 2006/12/05 10 kmacy kmacy_storage:sun4v_pmap_corruption 2006/11/09 2307 kmacy kmacy_storage:xen_work_current 2008/02/23 5 kmacy kmacy:storage:toehead 2007/01/14 4 kmacy kmacy_storage:sam_wifi 2007/05/13 15 kmacy kmacy_serendipity:sam_wifi 2006/12/29 61 kmacy kmacy_storage:sun4v_work_superpages 2007/10/21 3 kmacy kmacy_home:ethng_ref 2006/04/05 28 kmacy kmacy_storage:sun4vtmp 2006/07/31 8 kmacy kmacy_storage:sun4v_work_experimental_sux 2008/02/26 29 kris kris_16core 2008/06/20 25 kris kris_zoo_superpages 2008/07/19 115 kris kris_zoo1 2008/07/21 22 kris kris_zoo_tty 2008/03/13 2 kris kris_barc1 2008/02/21 60 kris kris_zoo_net 2008/06/21 8 kris kris_zoo6 2008/02/17 2 kris kris_gumby5 2008/01/18 1 kris kris_gumby2a 2008/07/14 99 kris kris_pointyhat 2008/06/20 34 kris kris_zoo_rwatson_udp 2008/07/12 1 kris kris_zoo_vimage 2006/07/07 1 lawrance dirk 2008/07/07 996 lqlee fbsd 2007/01/26 42675 lsc loomis 2007/06/22 3068 marks marks_macbook 2006/05/09 148 marks marks_laptop 2006/11/24 5 mdodd mdodd_ibmtp600e 2005/07/06 3767 mdodd mdodd_ms6167 2004/04/16 1 mini mini_shim 2007/05/17 2 mlaier mlaier_testlap 2008/04/29 2 mlaier mlaier_amd64 2008/05/21 3 murray murray_hilbert_django 2005/12/25 1 nork nork_pelsia 2007/03/30 35439 nsouch hglee_darkstar 2007/01/19 10 nsouch nsouch_armor 2008/05/01 7 peter peter_macbook 2008/04/19 1 peter peter_melody 2005/05/22 1 peter peter_hub 2007/07/03 34 peter peter_ia64 2005/02/27 1 phantom phantom_eagle 2006/03/16 1 philip philip_loge 2008/05/25 6 phk phk_critter 2008/03/12 1 phk phk_hex 2006/09/27 3 pjd pjd_lcf 2006/04/11 3 pjd pjd_slayer 2004/12/08 2 pjd_ro pjd_czort 2008/02/07 1 pramod pramod_linux 2008/07/23 7 rdivacky rdivacky_witten 2007/10/29 5 rink rink_pitchfork2 2007/06/17 6156 rink rink_pitchfork 2008/05/23 6299 rink rink_vian 2006/02/03 1 roam roam_straylight 2008/04/11 5 rrs rrs-mips2-jnpr 2008/01/22 1 rrs mips_rrs 2005/07/13 1 rwatson rwatson_nutmeg 2008/04/19 2 rwatson rwatson_noisier 2008/04/14 19 rwatson rwatson_zoo 2008/01/21 1 rwatson rwatson_cinnamon_netisr2 2006/06/13 14 rwatson rwatson_paprika 2008/04/19 3 rwatson rwatson_noisy 2006/10/26 34504 samy samy_viva 2008/04/24 1 sat sat_amilo 2008/04/01 2 scottl scottl-deimos 2007/02/19 31599 simokawa simokawa_tora 2004/11/19 3 simokawa simokawa_ett 2004/07/09 1 simokawa simokawa_tora2 2006/05/29 1 soc-bushman soc-bushman_stinger 2005/10/03 11 soc-emily soc-emily_beastie 2006/01/08 1 soc-polytopes polytopes_kafka 2006/09/04 9 ssouhlal ssouhlal-warp9 2008/03/20 1 swise swise:vic10:iwarp 2007/12/28 13 ticso ticso 2004/12/19 1 tjr tjr_yuiop 2004/03/24 3 tjr tjr_vm 2004/09/20 19 tjr tjr_dev 2008/01/21 30 trhodes trhodes_local 2007/01/21 2 tyler orange 2008/05/01 2535 ups ups_tinto 2005/06/13 4313 ups ups_palm 2007/07/20 4 ups ups_giant 2008/01/19 1 wkoszek wkoszek_sledge 2008/06/08 3147 wkoszek wkoszek_laptop 2008/05/13 1 wwesolowsky wadew-ports Clients with unknown user: From mexas at bristol.ac.uk Thu Aug 28 10:37:38 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Aug 28 10:37:45 2008 Subject: firefox build fails on alpha In-Reply-To: <20080819155839.GA27817@mech-cluster238.men.bris.ac.uk> References: <20080819155839.GA27817@mech-cluster238.men.bris.ac.uk> Message-ID: <20080828103728.GA22460@mech-cluster238.men.bris.ac.uk> I had a confirmation that firefox3 builds fine on amd64 under 7- and 8- branches. I therefore wonder if my problems are due to the fact that the build on alpha is done using gcc-3.4.6. Accordingly, I'd like to try to build this port with gcc42 (4.2.5). What is the easiest way to build this port with gcc42? Can I specify it in make.conf somehow? Do I need to redefine the default C, c++ compilers only? Linker? thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From freebsd at sopwith.solgatos.com Thu Aug 28 16:43:02 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Thu Aug 28 16:43:09 2008 Subject: firefox3 from ports? In-Reply-To: Your message of "Thu, 28 Aug 2008 14:36:45 -0000." Message-ID: <200808281641.QAA00630@sopwith.solgatos.com> [ -alpha@ added ] > > From what I gather the problems could show up on other > > 64-bit platforms. Alignment requirements vary with CPU arch, but is not a 32 vs 64 bit issue. > > warning: cast from ... to ... increases > > required alignment of target type > > No such warnings on amd64. I think they only show up on architectures > that require strict alignment, and amd64 doesn't. > FWIW, building firefox on OpenBSD/alpha and /sparc64 produces lots > of these warnings, but after all the pointer casting games are done, > the actual accesses still come out properly aligned and firefox > runs. Very interesting. Are you saying that the compiler warnings are wrong? Are you saying that a 2nd cast is done before the actual access which undoes the increase in alignment? Do you know for certain that the code in question is getting executed? Given the large amount of code in firefox, and the large number of features, I can imagine that lots of code only gets executed under rare occasions. > > What is the easiest way to build this port with gcc42? Try setting your PATH so that gcc42 is first. Verify by running "gcc -v". Are the alignment warnings the only remaining compiler warnings? From mexas at bristol.ac.uk Thu Aug 28 17:12:46 2008 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Aug 28 17:12:54 2008 Subject: firefox3 from ports? In-Reply-To: <200808281641.QAA00630@sopwith.solgatos.com> References: <200808281641.QAA00630@sopwith.solgatos.com> Message-ID: <20080828171237.GA71953@mech-cluster238.men.bris.ac.uk> On Thu, Aug 28, 2008 at 09:41:46AM +0100, Dieter wrote: > [ -alpha@ added ] > > > > From what I gather the problems could show up on other > > > 64-bit platforms. > > Alignment requirements vary with CPU arch, but is not a 32 vs 64 bit issue. > > > > warning: cast from ... to ... increases > > > required alignment of target type > > > > No such warnings on amd64. I think they only show up on architectures > > that require strict alignment, and amd64 doesn't. > > > FWIW, building firefox on OpenBSD/alpha and /sparc64 produces lots > > of these warnings, but after all the pointer casting games are done, > > the actual accesses still come out properly aligned and firefox > > runs. > > Very interesting. Are you saying that the compiler warnings are wrong? > Are you saying that a 2nd cast is done before the actual access which > undoes the increase in alignment? Do you know for certain that the code > in question is getting executed? Given the large amount of code in > firefox, and the large number of features, I can imagine that lots of > code only gets executed under rare occasions. > > > > What is the easiest way to build this port with gcc42? > > Try setting your PATH so that gcc42 is first. Verify by running > "gcc -v". I added this to /etc/make.conf: # Build ports/www/firefox3 with the latest gcc .if ${.CURDIR:M*/www/firefox3*} USE_GCC=4.2+ .endif this seems to work, however the error and the warnings are very similar if not identical. Then I disabled #CXXFLAGS += $(WARNINGS_AS_ERRORS) in a Makefile in a particular directory which gave me the error. I did this reluctantly, following the advice from firefox developer: --- Comment #12 from Benjamin Smedberg [:bs] (bsmedberg) 2008-08-28 +06:45:09 PDT --- These are warnings. They are *probably* harmless. To turn off warnings-as-errors for this directory, do: make WARNINGS_AS_ERRORS= from https://bugzilla.mozilla.org/show_bug.cgi?id=449373 after that the compilation went ahead with many many alignment warnings. > > Are the alignment warnings the only remaining compiler warnings? there might have been other, but the alignment was a clear champion. Now I get error on linking: gmake[3]: Entering directory `/usr/ports/www/firefox3/work/mozilla/toolkit/library' rm -f libxul.so g++42 -I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsCompressedCharMap.o nsBidiUtils.o nsRDFResource.o -pthread -Wl,-rpath-link,../../dist/bin -Wl,--whole-archive ../../embedding/browser/gtk/src/libgtkembedmoz.a ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libxpconnect.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libpref.a ../../staticlib/components/libcaps.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libchrome.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libxmlextras.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libmozfind.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libxpinstall.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libcomposer.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libintlapp.a ../../staticlib/components/libfileview.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libucvmath.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libsystem-pref.a ../../staticlib/components/libgkgfxthebes.a ../../staticlib/components/liboji.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libgkgfx.a ../../staticlib/libgfxshared_s.a ../../staticlib/libmozreg_s.a ../../staticlib/libmorkreader_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libgfxpsshar.a ../../staticlib/libthebes.a ../../staticlib/libjsj.a -Wl,--no-whole-archive -L../../dist/lib -lsqlite3 -Wl,-Bsymbolic -lc -L../../dist/bin -L../../dist/lib -L../../dist/bin -L../../dist/lib -L../../jpeg -lmozjpeg -L../../modules/libimg/png -lmozpng -L../../dist/bin -lmozlcms -L../../dist/bin -lmozjs -L../../dist/bin -L../../dist/lib -lcrmf -lsmime3 -lssl3 -lnss3 -lnssutil3 -lsoftokn3 -L/usr/lib -lz -pthread -L/usr/local/lib -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lz -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -liconv -pthread -L/usr/local/lib -lcairo -lfreetype -lz -lfontconfig -L/usr/local/lib -pthread -L/usr/local/lib -lXrender -lcairo -lX11 -L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread -L/usr/local/lib -lX11 -L/usr/local/lib -lXft -lXrender -lfontconfig -lfreetype -lz -lX11 -pthread -L/usr/local/lib -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lz -lfontconfig -lgmodule-2.0 -lX11 -lXfixes -lgobject-2.0 -lglib-2.0 -liconv -lXt -lgthread-2.0 -L/usr/local/lib -lfreetype -lz -lm -pthread -pthread -L/usr/local/lib -liconv ../../staticlib/components/libxpconnect.a(xpcwrappednative.o)(.text+0x303c): In function `XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)': : undefined reference to `NS_InvokeByIndex_P' ../../staticlib/components/libxpconnect.a(xpcwrappednative.o)(.text+0x307c): In function `XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)': : undefined reference to `NS_InvokeByIndex_P' ../../staticlib/components/libgklayout.a(txXPCOMExtensionFunction.o)(.text+0xc1c): In function `txXPCOMExtensionFunctionCall::evaluate(txIEvalContext*, txAExprResult**)': : undefined reference to `NS_InvokeByIndex_P' ../../staticlib/components/libgklayout.a(nsXTFInterfaceAggregator.o)(.text+0x2cc): In function `nsXTFInterfaceAggregator::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)': : undefined reference to `NS_InvokeByIndex_P' ../../staticlib/components/libgklayout.a(nsXTFWeakTearoff.o)(.text+0x208): In function `nsXTFWeakTearoff::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)': : undefined reference to `NS_InvokeByIndex_P' ../../staticlib/libxpcom_core.a(nsProxyEvent.o)(.text+0x944): more undefined references to `NS_InvokeByIndex_P' follow ../../staticlib/libxpcom_core.a(xptcinvoke_freebsd_alpha.o)(.text+0x44): In function `XPTC_InvokeByIndex': : undefined reference to `$invoke_copy_to_stack..ng' ../../staticlib/libxpcom_core.a(xptcstubs_freebsd_alpha.o)(.text+0x40): In function `SharedStub': : undefined reference to `$PrepareAndDispatch..ng' collect2: ld returned 1 exit status gmake[3]: *** [libxul.so] Error 1 gmake[3]: Leaving directory `/usr/ports/www/firefox3/work/mozilla/toolkit/library' The final 4 lines refer to 2 xptc* files, which I copied from FF2 distro and modified myself, so that probably means I have to review these 2 files. thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423