Re: Lack of Flash support is no longer acceptable. Bounty established...
On Thu, Jun 19, 2008 at 9:59 PM, David E. Thiel <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 02:37:48PM -0700, John Kozubik wrote: >> FreeBSD is not useful as a desktop environment without the ability to >> support Flash in a stable, well-performing fashion. > > Nonsense. This presumes anything "useful" has ever been written in > flash. Believe it or not, there is useful content on the web in Flash : Google [Flash filetype:swf site:nasa.gov] (without the brackets). - Murray ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Jun 20, 2008, at 12:01 AM, Murray Stokely wrote: On Thu, Jun 19, 2008 at 9:59 PM, David E. Thiel <[EMAIL PROTECTED]> wrote: On Thu, Jun 19, 2008 at 02:37:48PM -0700, John Kozubik wrote: FreeBSD is not useful as a desktop environment without the ability to support Flash in a stable, well-performing fashion. Nonsense. This presumes anything "useful" has ever been written in flash. Believe it or not, there is useful content on the web in Flash : Google [Flash filetype:swf site:nasa.gov] (without the brackets). Yeah, seriously! Never mind all the video content I am desperate to view on Hulu! ;-) I think my latest Rosetta Stone is Flash9 now too :'( -matt -- Matt Olander CTO, iXsystems - "Servers for Open Source" http://www.iXsystems.com Public Relations, The FreeBSD Project http://www.FreeBSD.org BSD on the Desktop! http://www.pcbsd.org Phone: (408)943-4100 ext. 113Fax: (408)943-4101 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Decent 3D acceleration in 64bit mode?
On Thu, Jun 19, 2008 at 05:36:44PM -0400, Chuck Robey wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mike Meyer wrote: > > On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> > > wrote: > > > >> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking <[EMAIL PROTECTED]> > >> wrote: > >>> Given that Nvidia aren't offering a driver for their cards for 64bit > >>> FreeBSD, is anyone else having success using another (preferably > >>> PCI-E) card with 3D acceleration? > >> I'd love to be told I'm wrong, but my understanding is that the issues > >> blocking the nvidia driver would also effectively block a driver for which > >> we had the source. > > > > Is there an open source driver with good 3D acceleration? > > > > > Could I ask, does anyone here know the reason (even in general) that the > Nvidia > driver isn't working on the i386? > > I mean, I was wondering what might be my next project ... I have the > machinery, > and the source code is totally available, it's not a matter of Nvidia giving > out > a binary-only module, right? So, is anything more known? you might want to port nouveau (http://nouveau.freedesktop.org/wiki/) to FreeBSD. that would be a great thing to have ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Fri, Jun 20, 2008 at 08:39:06AM +0200, Alexander Leidinger wrote: > Quoting John Kozubik <[EMAIL PROTECTED]> (from Thu, 19 Jun 2008 > 14:38:11 -0700 (PDT)): > > >First, a bounty has been posted here: > > > >http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > > > From the site: > ---snip--- > I will pay $200 to whoever can compose a working and stable recipe for > running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 > on FreeBSD 6.x. This shouldn't be that hard - in fact, there is > already a linux-flashplugin9 port. > ---snip--- > > Comments from other people with some more money not included here... > > And now the sad reality check: linux-flashplugin9 will _never_ work on > 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). > > Getting it to work on 7.x is possible. "All what you need" is > nspluginwrapper to get it running in the native > firefox/opera/whatever, and someone who is willing to debug the > linuxulator (on -current, as there is a more complete 2.6 > compatibility there, and this can be MFCed to 7.x) and find the > bug/problem which is causing the crashes. Whoever is willing to tackle > this: head over to emulation@ (CCed) and ask what debugging > possibilities we have in the linuxulator. I tried to debug the flash9 and failed badly. It might be that I overlooked something trivial but... the flash9 is a big binary-only monster and basically the only trace of what its doing you can get is a syscall-trace. Which is not that much useful. I didnt find any missing syscalls or something like that and the fail is a complete mystery for me otoh I looked at this a LOONG time ago. I might want to look at it again (after some other things settle) anyway... I dont think that flash9 crashes are related to 2.6 emulation in any way. iirc it runs (and crashes) on 2.4 as well. I remember it crashes in $the_thing_that_ff_uses_to_report_bugs which was some proprietary app which got replaced in ff3.0, you might want to check what happened. anyway - if someone wants to debug this, feel free to contact me, I am willing to help roman _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
Believe it or not, there is useful content on the web in Flash : > > Google [Flash filetype:swf site:nasa.gov] > (without the brackets). There might be useful content, but that surely doesnt mean FreeBSD itself as a desktop isnt usable, I think saying using firefox/flash for flash based websites is difficult at best. but FreeBSD as a desktop is plainly very usable ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Jaakko Heinonen escribió: On 2008-06-17, Gabor Kovesdan wrote: egrep: empty (sub)expression I've looked at this and I have a patch with a workaround: http://kovesdan.org/patches/grep.dougb.diff Unfortunately this breaks things. For example: $ grep -E '(test||test)' /dev/null grep: parentheses not balanced $ grep -E '(test|\|)' /dev/null grep: parentheses not balanced $ grep -E '\(|test)' /dev/null (should give an error but it hangs) Ugly enough, but seems to be fixed in my working copy. Thanks for the report. Gabor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
Quoting John Kozubik <[EMAIL PROTECTED]> (from Thu, 19 Jun 2008 14:38:11 -0700 (PDT)): First, a bounty has been posted here: http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html From the site: ---snip--- I will pay $200 to whoever can compose a working and stable recipe for running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 on FreeBSD 6.x. This shouldn't be that hard - in fact, there is already a linux-flashplugin9 port. ---snip--- Comments from other people with some more money not included here... And now the sad reality check: linux-flashplugin9 will _never_ work on 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). Getting it to work on 7.x is possible. "All what you need" is nspluginwrapper to get it running in the native firefox/opera/whatever, and someone who is willing to debug the linuxulator (on -current, as there is a more complete 2.6 compatibility there, and this can be MFCed to 7.x) and find the bug/problem which is causing the crashes. Whoever is willing to tackle this: head over to emulation@ (CCed) and ask what debugging possibilities we have in the linuxulator. Note: AFAIK linux-flashplugin9 is not completely stable on linux either... Bye, Alexander. -- Leela: Well, goodnight. I'm gonna go make my dinners for the next month and freeze them. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
Quoting Roman Divacky <[EMAIL PROTECTED]> (from Fri, 20 Jun 2008 10:04:16 +0200): On Fri, Jun 20, 2008 at 08:39:06AM +0200, Alexander Leidinger wrote: Quoting John Kozubik <[EMAIL PROTECTED]> (from Thu, 19 Jun 2008 14:38:11 -0700 (PDT)): >First, a bounty has been posted here: > >http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > From the site: ---snip--- I will pay $200 to whoever can compose a working and stable recipe for running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 on FreeBSD 6.x. This shouldn't be that hard - in fact, there is already a linux-flashplugin9 port. ---snip--- Comments from other people with some more money not included here... And now the sad reality check: linux-flashplugin9 will _never_ work on 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). Getting it to work on 7.x is possible. "All what you need" is nspluginwrapper to get it running in the native firefox/opera/whatever, and someone who is willing to debug the linuxulator (on -current, as there is a more complete 2.6 compatibility there, and this can be MFCed to 7.x) and find the bug/problem which is causing the crashes. Whoever is willing to tackle this: head over to emulation@ (CCed) and ask what debugging possibilities we have in the linuxulator. I tried to debug the flash9 and failed badly. It might be that I overlooked something trivial but... the flash9 is a big binary-only monster and basically the only trace of what its doing you can get is a syscall-trace. Which is not that much I think enabling the the linuxulator debug stuff and maybe adding some more printfs at some places can reveal some more stuff... with some in-deep reviewing of what happens. useful. I didnt find any missing syscalls or something like that and the fail is a complete mystery for me otoh I looked at this a LOONG time ago. Which is in indication that there are some (subtle) differences between the linuxulator and the real linux we have to track down. I might want to look at it again (after some other things settle) anyway... I dont think that flash9 crashes are related to 2.6 emulation in any way. iirc it runs (and crashes) on 2.4 as well. I remember it crashes in Hmmm... now I'm not sure anymore, but I thought we had reports that it runs better with 2.6... Bye, Alexander. -- I wish I was a sex-starved manicurist found dead in the Bronx!! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 7.0: sockets stuck in CLOSED state...
Dear All, Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to FreeBSD 7.0 amd64. After upgrading I noticed a weird error/bug. It seems that after several thousand TCP connections some seem to hang in 'CLOSED' state. netstat -n gives: ... tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED ... These never go away; they gradually increase and increase until the application starts giving errors (probably because some socket or filedescriptor limit is reached). When the application is killed these entries disappear. The application in question is a self written DNS server, multithreaded, and running fine for years without any troubles on both BSD 5.x as well as 6.x. Also 32bits as well as 64bits on 6.x. Ofcourse that doesn't mean that the application is error free, however, after doing extensive testing I really can not find anything wrong with the application itself, so I'm thinking maybe there's a change somewhere that causes this? I know that tcp/network has been completely redone... What basically happens in the application is this: - one main tcp thread runs an infinite while loop waiting for new connections to arrive - as soon as one arrives a new thread is spawned that handles the newly created stream - it reads some bytes, writes some bytes, then closes it - thread exits What appears to happen is this: after the new thread is spawned it tries to read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and therefore closes the sockets and calls pthread_exit. However in netstat that same stream oftenly appears to have bytes 'stuck' in the in queue... I really can't see how this can cause hanging sockets in 'CLOSED' state. Even if the incoming queue isnt read entirely a call to close should close it. Also I really can't find any documentation in netstat, or elsewhere, about the 'CLOSED' state... Any help would greatly be appreciated! Kind Regards, Ali Niknam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Fri, 2008-06-20 at 08:39 +0200, Alexander Leidinger wrote: > Quoting John Kozubik <[EMAIL PROTECTED]> (from Thu, 19 Jun 2008 > 14:38:11 -0700 (PDT)): > > > First, a bounty has been posted here: > > > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > > Maybe the bounty would be better spent here, This was from an email on the gnome list from Joe Marcus Clarke <[EMAIL PROTECTED]> "As to the point about Flash, Kris also mentioned that he has the ear of someone at Adobe who was hinting that a capable developer willing to sign an NDA could be given code to work on a native Flash plug-in port. This could bode well for PC-BSD and FreeBSD should someone step up to do this work." > From the site: > ---snip--- > I will pay $200 to whoever can compose a working and stable recipe for > running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 > on FreeBSD 6.x. This shouldn't be that hard - in fact, there is > already a linux-flashplugin9 port. > ---snip--- > > Comments from other people with some more money not included here... > > And now the sad reality check: linux-flashplugin9 will _never_ work on > 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). > > Getting it to work on 7.x is possible. "All what you need" is > nspluginwrapper to get it running in the native > firefox/opera/whatever, and someone who is willing to debug the > linuxulator (on -current, as there is a more complete 2.6 > compatibility there, and this can be MFCed to 7.x) and find the > bug/problem which is causing the crashes. Whoever is willing to tackle > this: head over to emulation@ (CCed) and ask what debugging > possibilities we have in the linuxulator. > > Note: AFAIK linux-flashplugin9 is not completely stable on linux either... > > Bye, > Alexander. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cross platform building best practices (building 6 on 7)
On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <[EMAIL PROTECTED]> wrote: >> Hello Folks: >> >> I've done a lot of Googling and scouring the lists about this >> particular subject so I apologize for rehashing it. However, I'm >> still confused on what's the best way to perform BSD cross platform >> builds. Ideally what I want to have is an environment whereby I can >> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >> could check out a 6.1 release version, perform make world, and then >> use the output of that build as either a basis for a jail or a >> toolchain. However, as noted by previous threads, 6.x doesn't build >> on a 7.x due to gcc4/binutils compatibility issues (please correct me >> if I'm wrong). I then thought I could potentially download a patched >> binutils, copy it into src/contrib/binutils and that would potentially >> fix it. No dice (and I'm still debugging why since this binutils >> package DOES build outside of the make world infrastructure without >> issue, this very well could be pilot error on my part since I didn't >> update the VERSION string and didn't trim the source files as per the >> FreeBSD-deleteList etc.). >> >> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >> this point I believe I'm diverged from the path of FreeBSD build >> enlightenment! Moreover, if would be NICE if I could bootstrap the >> normal dev tools from the exiting make world build tree. I'm not yet >> ready for a lot of hackery on the build tree without asking around. >> :D! >> >> Does anyone due cross-platform builds (without host virtualization)? >> >> Thanks! >> >> -aps > > (I'll stick to just hackers@ because I don't want to pollute > questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). > You touched on an important point. There were some code quality issues > (I think) with 6.x that were resolved moving to 7.x, which caused > gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! > gcc-4.2.x requires a newer version of binutils, just because (for API > / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. > What you should probably do is create a jail then do your development > for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) > do 8.x development in yet a third. Jail's are a much better way to > isolate things such that you don't have to worry about toolchain > issues like these and are able to setup a sourcebase as the devs > intended it (for the most part; you may run into issues with sysctls > and virtual kernel stuff like that, but cest la vie... there isn't a > better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cross platform building best practices (building 6 on 7)
Alexander Sack wrote: On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <[EMAIL PROTECTED]> wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) One thing we always strive for in FreeBSD is an upgrade path. As a general rule, a newer system should be able to run a jail populated with an earlier system. There are some small exceptions, for example you may need a new version of netstat, ps and libkvm in your jail. possibly grab them from the /rescue on the new system so they are statically linked. also 8.x systems will require that threaded programs from 6.x be dynamically linked so that they can be remapped to use libthr instead of libkse as libkse is not supported in 8. asside from those I think that just about every thing else should be fine.. I've run a FreeBSD 1.1 chroot on a freeBSD 7 system (I had to make 1 very small fix). At Ironport we build 4.x binaries on 6.x systems by spinning off a 4.x chroot as prart of the build process. (they need to link with 4.x third part
Re: Cross platform building best practices (building 6 on 7)
On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer <[EMAIL PROTECTED]> wrote: > Alexander Sack wrote: >> >> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper <[EMAIL PROTECTED]> >> wrote: >>> >>> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <[EMAIL PROTECTED]> >>> wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps >>> >>> (I'll stick to just hackers@ because I don't want to pollute >>> questions@ unnecessarily) >> >> Sorry I felt really bad actually cc'ing questions its just that my >> last groking produced many threads in freebsd-questions as opposed to >> hackers. I'll try to be more attentive to my posts (I have a habit >> cc'ing multiple forums because sometimes they apply but questions is >> for normal troubleshooting, not cross-platform build issues!). >> >>> You touched on an important point. There were some code quality issues >>> (I think) with 6.x that were resolved moving to 7.x, which caused >>> gcc-4.2.x to barf. >> >> Probably but I'm not trying to point fingers! :D! >> >>> gcc-4.2.x requires a newer version of binutils, just because (for API >>> / usage compatibility). >> >> Yea understood. To be honest, this isn't documented very readily. I >> first thought it was pilot error on me, then I decided to take a look >> at what failed to compile (I believe it was an innocent extern). And >> then got lost in gcc/binutils hell. Luckily I've smelled this problem >> before and after some research confirmed by suspicion. >> >>> What you should probably do is create a jail then do your development >>> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >>> do 8.x development in yet a third. Jail's are a much better way to >>> isolate things such that you don't have to worry about toolchain >>> issues like these and are able to setup a sourcebase as the devs >>> intended it (for the most part; you may run into issues with sysctls >>> and virtual kernel stuff like that, but cest la vie... there isn't a >>> better way I know of than that outside of running a VM). >> >> I figured you were going ot say that Garrett. Well OK, but I still >> need to bootstrap my dev environment for 6.x development on 7.x. >> Since binutils compatibility makes my 6.x make world barf on 7.x, >> where should I go? I HAVE not parsed through a lot of the build >> infrastructure yet but it would seem to be IF make world bootstraps >> the world including the development tools, why can't I update >> binutils/gcc inplace and then compile (or is this a regression issue >> which I failed to grasp). Or do I need to update binutils on my >> *host* system itself? i.e. what I'm really asking is does make world >> bootstrap the right bintuils/gcc etc. and then use THAT to compile the >> rest or does it just perform a host build of everything and plops it >> in DESTDIR? >> >> Hope I make some sense here (still a n00b) > > One thing we always strive for in FreeBSD is an upgrade path. > > As a general rule, a newer system should be able to run a jail > populated with an earlier system. There are some small exceptions, > for example you may need a new version of netstat, ps and libkvm > in your jail. possibly grab them from the /rescue on the new system > so they are statically linked. > also 8.x systems will require that threaded programs from 6.x be dynamically > li
Re: Cross platform building best practices (building 6 on 7)
Alexander Sack wrote: On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer <[EMAIL PROTECTED]> wrote: Alexander Sack wrote: On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <[EMAIL PROTECTED]> wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) One thing we always strive for in FreeBSD is an upgrade path. As a general rule, a newer system should be able to run a jail populated with an earlier system. There are some small exceptions, for example you may need a new version of netstat, ps and libkvm in your jail. possibly grab them from the /rescue on the new system so they are statically linked. also 8.x systems will require that threaded programs from 6.x be dynamically linked so that they can be remapped to use libthr instead of libkse as libkse is not supported in 8. So you are talking about binary/ABI compatibility yes? So I would assume what you are saying is I can take a 6.x system, create a filesystem tarball, drop it on a 7.x system and then create a jail out of it. exactly
Re: Cross platform building best practices (building 6 on 7)
Alexander Sack wrote: On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer <[EMAIL PROTECTED]> wrote: Alexander Sack wrote: On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <[EMAIL PROTECTED]> wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) One thing we always strive for in FreeBSD is an upgrade path. As a general rule, a newer system should be able to run a jail populated with an earlier system. There are some small exceptions, for example you may need a new version of netstat, ps and libkvm in your jail. possibly grab them from the /rescue on the new system so they are statically linked. also 8.x systems will require that threaded programs from 6.x be dynamically linked so that they can be remapped to use libthr instead of libkse as libkse is not supported in 8. So you are talking about binary/ABI compatibility yes? So I would assume what you are saying is I can take a 6.x system, create a filesystem tarball, drop it on a 7.x system and then create a jail out of it. asside fr
Re: Cross platform building best practices (building 6 on 7)
On Fri, Jun 20, 2008 at 6:02 PM, Julian Elischer <[EMAIL PROTECTED]> wrote: > Alexander Sack wrote: >> >> On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer <[EMAIL PROTECTED]> >> wrote: >>> >>> Alexander Sack wrote: On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack <[EMAIL PROTECTED]> > wrote: >> >> Hello Folks: >> >> I've done a lot of Googling and scouring the lists about this >> particular subject so I apologize for rehashing it. However, I'm >> still confused on what's the best way to perform BSD cross platform >> builds. Ideally what I want to have is an environment whereby I can >> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >> could check out a 6.1 release version, perform make world, and then >> use the output of that build as either a basis for a jail or a >> toolchain. However, as noted by previous threads, 6.x doesn't build >> on a 7.x due to gcc4/binutils compatibility issues (please correct me >> if I'm wrong). I then thought I could potentially download a patched >> binutils, copy it into src/contrib/binutils and that would potentially >> fix it. No dice (and I'm still debugging why since this binutils >> package DOES build outside of the make world infrastructure without >> issue, this very well could be pilot error on my part since I didn't >> update the VERSION string and didn't trim the source files as per the >> FreeBSD-deleteList etc.). >> >> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >> this point I believe I'm diverged from the path of FreeBSD build >> enlightenment! Moreover, if would be NICE if I could bootstrap the >> normal dev tools from the exiting make world build tree. I'm not yet >> ready for a lot of hackery on the build tree without asking around. >> :D! >> >> Does anyone due cross-platform builds (without host virtualization)? >> >> Thanks! >> >> -aps > > (I'll stick to just hackers@ because I don't want to pollute > questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). > You touched on an important point. There were some code quality issues > (I think) with 6.x that were resolved moving to 7.x, which caused > gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! > gcc-4.2.x requires a newer version of binutils, just because (for API > / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. > What you should probably do is create a jail then do your development > for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) > do 8.x development in yet a third. Jail's are a much better way to > isolate things such that you don't have to worry about toolchain > issues like these and are able to setup a sourcebase as the devs > intended it (for the most part; you may run into issues with sysctls > and virtual kernel stuff like that, but cest la vie... there isn't a > better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) >>> >>> One thing we always strive for in FreeBSD is an upgrade path. >>> >>> As a general rule, a newer system should be able to run a jail >>> populated with an ear
Looking for *cheap* embedded platform w- 2 ethernets
I'm looking for a cheap and small embedded platform to use as a portable vpn endpoint. It doesn't have to be fast, it just has to run *BSD. Any suggestions?? Thanks, Joe Joe McGuckin ViaNet Communications [EMAIL PROTECTED] 650-207-0372 cell 650-213-1302 office 650-969-2124 fax ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
