Re: Why is pkg_glob no longer working for me?
On Sun, Apr 28, 2013 at 12:00:02PM +, we recorded a bogon-computron collision of the free...@chthonixia.net flavor, containing: On Fri, Apr 26, 2013 at 02:54:59PM -0600, Tom Russo wrote: Anyone else have this issue? Or am I the only one left still using portupgrade and its associated tools? I use portupgrade and have noticed no failures. I use portupgrade and usually notice no failures. But every once in a while a package fails (for many reasons, either a download site that's down, or some change has been made that makes one package conflict with another, or you installed some dependent package with options that this new package doesn't like, or...). I have never used pkg_glob so I cannot address that. That's the only thing I have noticed that doesn't work. Portupgrade itself is fine. But pkg_glob is part of the portupgrade package, so if the issue is that it got broken in an upgrade, then it was an upgrade to portupgrade that did it. I have used portupgrade as you, for many ports, and have always seen failures printed to my terminal at the end of the mass upgrade with an alert to that effect; just like for a single port. It seems that you are not seeing that report? Oh, that works just fine. I was simply tossing out a single use case in too terse a manner. My apologies for oversimplifying. Here's what I really meant by that example: Let's say some package, foobar, has been updated, but lots and lots of packages depend on it and UPDATING tells you to force upgrade everything that depends on it. So... You run a portupgrade -fr foobar and after hours and hours of successful recursive portupgrading, some package (and everything that depend on it) fails. You dig down to figure out why it failed (let's say, it was a broken download, or something really trivial like that), then fix the problem, and want the portupgrade to continue where it left off. You don't want to just redo portupgrade -fr foobar because then it'll start all over, and it's already tied up your machine for hours. What you really want is: portupgrade -fr -x '=(a date/time after portupgrade exited before)' foobar But before you do that, you double check which ones will be upgraded now: pkg_glob -r -x '=(the same date/time)' foobar One assumes that if the latter gives you a list of packages that seems reasonable (and doesn't appear to list packages it already did successfully), then the former will only force upgrades to the same list. Now, the real reason I posted this message in the first place was that on Thursday I did a portupgrade and it upgraded some 20 packages, all of them successful. A day later, long after all traces of portupgrade output were gone from any screen I had, I discovered one of my projects for work started getting build failures (related to /usr/local/lib/gcc46/libstdc++.so somehow not being searched at link time, using precisely a (extraordinarily complex openmpi-based) build process that had worked perfectly on Thursday) --- and there had been no changes other than that portupgrade run (I started portupgrade before I left work on Thursday, and on Friday morning portupgrade was done and my work build was busted). Now, I needed to figure out what exactly had been done by that portupgrade, to track down why /usr/local/lib/gcc46/libstdc++.so was suddenly no longer being searched for externals when my code was linking, even though it had worked just yesterday --- clearly, some package that I'm actually using in this build got touched in some way, but which one, and how? Pkg_glob is the tool that could have helped me. But pkg_glob no longer works to show me what, exactly, had been upgraded. I still don't actually know what upgraded package broke my build, but I did ultimately find a workaround to get me past it. It would be nice to be able to use that tool again, because it has come in very handy many times in the past. Hence my original post, with a dramatically simpler and less verbose use case described in the intro. So, the question remains: why did it stop working, and how can I make it work again? -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM echo prpv_a'rfg_cnf_har_cvcr | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Why is pkg_glob no longer working for me?
I used to be able to run pkg_glob to see what packages have been updated since a given date. For example, if I do a big 'portupgrade -fr somepackage' and wait overnight, then in the morning find a handful had failed, I often find it helpful to do something like: pkg_glob -r somepackage -x '= 2013-04-24' to see what packages depend on somepackage but weren't updated when I did the portupgrade on the 24th. But now, I find that pkg_glob always returns absolutely nothing if I specify a date. I did a portupgrade -a on Thursday the 25th of April, and when I try to see which ports actually got updated with pkg_glob '=2013-04-24', it prints nothing. This has been happening for a few weeks, at least, and I wonder an update to the portupgrade package busted it. I have tried rebuilding the package db and ports db using pkgdb and portsdb, with no change in behavior. I tried looking at /var/db/pkg to see if the modification times of directories there might help me answer my question, but far more directories have been touched than packages actually updated (there were, as I recall, 20 pending package upgrades when I started the process). Anyone else have this issue? Or am I the only one left still using portupgrade and its associated tools? -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM echo prpv_a'rfg_cnf_har_cvcr | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: gEDA, SPICE, electronic cad/simulation
On Sun, Oct 28, 2012 at 11:27:25AM -0600, we recorded a bogon-computron collision of the ru...@bogodyn.org flavor, containing: 3) SPICE (and ng-spice) always uses the first character of a device line to determine the type of the device. While most designers will draw a circuit with an IC in it and give the IC a name like U1, the character u in the first position on a device line means lossy transmission line in spice, not IC. Thus, in your netlist you're simply telling the simulator to create a lossy transmission line using nodes 0, 4, 3 and +9v as its four ports, and it's getting confused by all the extra parameters on the line. My mistake. U is the Uniform Lossy RC line, not the lossy transmission line. The URC device takes 3 nodes and a model name, and so it's used 0, 4, and 3 as the nodes, and then gotten confused about the unknown model named +9v. It then gets confused about the remaining parameters on the line. Point remains the same, you can't specify an IC named U1 in a spice netlist by calling the device U1. You need to use an X subcircuit instantiation line and an associated .subckt subcircuit definition. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit! --- The Tick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: OT: gEDA, SPICE, electronic cad/simulation
that I can't be absolutely certain that gschem's 555 symbol has its pins defined so that it maps exactly onto the input nodes of the UA555 subcircuit model in the forums post I pointed you at. You will have to check for yourself. 4) Your circuit as is is having a really hard time in the solvers (not surprising, given all the errors), so SPICE is using its gmin stepping process trying to force a solution. 5) You are attempting to use expressions somewhere (on a print line?) and this is not a supported feature in most free versions of spice. 6) gnetlist will dutifully produce a netlist from the schematic you give it, but unless you've prepared the netlist with an understanding of how gnetlist is going to process it, you can get garbage. While gEDA/gschem/gnetlist/ng-spice are cool tools, they are not easy to dive into without a previous knowledge of spice. You can try looking at the internal help in ngspice. Just fire up ngspice and type help, then explore. This will not teach you the answers to your specific issue, but *will* let you know what the format of various netlist features are. For more detail, you're better off with a textbook on SPICE simulation, and probably need to ask more detailed questions on a gEDA mailing list. HTH, T. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit! --- The Tick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: doom, quake, hexen
On Mon, Aug 20, 2012 at 06:28:57PM +, we recorded a bogon-computron collision of the free...@edvax.de flavor, containing: On Tue, 21 Aug 2012 00:05:17 +0700, Victor Sudakov wrote: Please advise if there are any 3D shooters in the ports collection which work out of the box on 9.0-STABLE (amd64)? [...] Maybe even other older DOS shooters (Duke Nukem 3D, Chasm, Shadow Warrior, Dark Forces, Blood and so on) could be easily run using a VM or emulator? If you have the original Duke Nukem 3D install CDs for DOS, you can use the eduke32 port rather than a VM or DOS emulator. eduke32 is a port of the graphics engine for Duke 3D that renders using OpenGL, and uses the original game files from the CD (requires them, actually). There's just one file you need to copy off the CD to make it work (game.con IIRC). There is also something called a High Resolution Pack (HRP) for eduke32 that updates the maps to higher res, but I've never been able to get the HRP to work on FreeBSD, even though it works and looks great on Linux. The eduke32 port once emitted a message telling you about the HRP and where to find it, but never explained how to install it or use it on BSD (and the HRP web site has only Windows and Linux-specific installers). Just looked, and it appears that this reference to the HRP is now removed from the FreeBSD port. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit! --- The Tick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
X Forwarding problems since upgrading to 6-Stable
I have three BSD machines running 6-Stable, all of them only recently upgraded from 5-STABLE. Ever since the upgrades, I cannot get remote hosts to which I've ssh'd to connect to the tunneled X server. For example: hostb ssh -X hostA hosta echo $DISPLAY localhost:10.0 hosta xev Xlib: connection to localhost:10.0 refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key xev: unable to open display 'localhost:10.0' hosta exit hostb ssh -Y hostA hosta echo $DISPLAY localhost:10.0 hosta xev Xlib: connection to localhost:10.0 refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key xev: unable to open display 'localhost:10.0' If hosta is not a FreeBSD machine, the *OPPOSITE* attempt works fine. For example, if hosta is my linux laptop: hosta ssh -X hostb hostb echo $$DISPLAY localhost:10.0 hostb xev [... xev starts up just fine and displays on the laptop...] But if the machine from which I'm sshing is one of my 6-stable BSD machines, it never works. All the 6-stable machines are running the latest ports, as I keep my ports tree csup'd and portupgrade regularly. I've googled the issue and the only thing I ever find is people answering you should use -Y instead of -X to enable 'trusted' forwarding. This clearly doesn't work for me, either. Since I am not seeing tons of recent references to this all over the net, I am pretty much concluding that I must have some kind of configuration mistake on my BSD machines' X or ssh setups, but I don't immediately see one. I thought I left my sshd config pretty much as it was out of the box, but perhaps I screwed something up. Can anyone suggest a place to start looking for the error? -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit! --- The Tick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Botched X.org upgrade, need help
On Fri, Nov 09, 2007 at 03:26:15AM +, we recorded a bogon-computron collision of the [EMAIL PROTECTED] flavor, containing: On Thursday 08 November 2007, Andrew Falanga said: On Nov 8, 2007 12:37 PM, Warren Block [EMAIL PROTECTED] wrote: On Thu, 8 Nov 2007, Andrew Falanga wrote: Well, at last I think it's botched. I really was following the directions [...] (WW) Warning, couldn't open module pcidata (II) UnloadModule: pcidata (EE) Failed to load module pcidata (module does not exist, 0) Fatal server error: Unable to load required base modules, Exiting... I had a very similar experience, with the X server reporting missing modules immediately after I thought I'd followed the upgrade instructions to the letter (including the portupgrade -a, migrating all the /usr/X11R6 stuff with mergebase, and various nvidia-driver caveats). Turns out that in my case the xorg-drivers and xorg-fonts ports had not been added by the upgrade process, probably because I had a missing metaport in my previous install. That was the one block of caveats I apparently missed. In the end, I was able to just do a make install of the xorg metaport and it picked up the missing two, then I was back in business. Perhaps that's what's going on with you? Or perhaps not --- I see you also mentioned you hadn't updated ModulePath, and perhaps that was the only reason you are having problems? I didn't see a follow-up saying that was it. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit! --- The Tick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Contradicting the answer to Re: Answering my own question Re: Iomega REV drive, FreeBSD 4.11
On Sun, Jul 24, 2005 at 10:21:55AM -0600, we recorded a bogon-computron collision of the [EMAIL PROTECTED] flavor, containing: I'm answering my own question on the mailing list, just to get what I found into the archives in case anyone else has this question. On Thu, Jul 21, 2005 at 08:33:47PM -0600, we recorded a bogon-computron collision of the [EMAIL PROTECTED] flavor, containing: I'm running FreeBSD 4.11. I last updated from STABLE in January: FreeBSD bogodyn.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Jan 22 13:10:32 MST 2005 [EMAIL PROTECTED]:/users2/obj/usr/src/sys/BOGODYN i386 I just purchased an external SCSI Iomga REV 35MB removable medium drive. [...] When I attach the device and camcontrol rescan all, I get this in the /var/log/messages: Jul 21 19:22:52 bogodyn /kernel: cd1: Iomega RRD 84.B Removable CD-ROM SCSI-4 device [...] That is, the drive is detected, but as a removable CDROM, This is not peculiar to BSD. Low-level SCSI utilities in the SCSI controller at boot time also fail to recognize this thing as a disk drive, and even on Windows it shows up as a CD-ROM. The only way to write data to it is to use a windows-only driver. And since it doesn't use an ISO-9660 file system, the only way to read data off of it is with a windows-only driver, too. So the thing is a paperweight unless one is using Windows. One can use the windows explorer to copy files into it, and one could use it to back up files if they're on a BSD machine shared by Samba. Useless for system recovery, but perhaps barely functional as a data backup. Live and learn. I just received a note from a member of the amanda-users mailing list, contradicting what I wrote above several weeks ago. Apparently the Iomega REV drive uses a UDF filesystem and functions as a DVD-RAM at the system level, even though it probes as a CD-ROM drive. This person has been using one as a backup device on a SuSE Linux box for a while. Since posting the original query I finally upgraded to FreeBSD 5.4. Unfortunately, to use it one requires read/write access to UDF filesystems, and BSD 5.4 has only read-only support for UDF. So to amend my earlier report of the uselessness of the Iomega REV drive: FreeBSD 4.11 can't use it because it lacks UDF support FreeBSD 5.x might be able to read them It would be possible, were there read/write support for UDF, to use the thing It is not limited to Windows, one needs only read/write UDF support. Which leads to a final question: Is there any work being done on read/write support for UDF filesystems? Might 6.0 get this capability? -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 The only thing you can do easily is be wrong, and that's hardly worth the effort. -- Norton Juster ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Answering my own question Re: Iomega REV drive, FreeBSD 4.11
I'm answering my own question on the mailing list, just to get what I found into the archives in case anyone else has this question. On Thu, Jul 21, 2005 at 08:33:47PM -0600, we recorded a bogon-computron collision of the [EMAIL PROTECTED] flavor, containing: I'm running FreeBSD 4.11. I last updated from STABLE in January: FreeBSD bogodyn.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Jan 22 13:10:32 MST 2005 [EMAIL PROTECTED]:/users2/obj/usr/src/sys/BOGODYN i386 I just purchased an external SCSI Iomga REV 35MB removable medium drive. [...] When I attach the device and camcontrol rescan all, I get this in the /var/log/messages: Jul 21 19:22:52 bogodyn /kernel: cd1: Iomega RRD 84.B Removable CD-ROM SCSI-4 device [...] That is, the drive is detected, but as a removable CDROM, This is not peculiar to BSD. Low-level SCSI utilities in the SCSI controller at boot time also fail to recognize this thing as a disk drive, and even on Windows it shows up as a CD-ROM. The only way to write data to it is to use a windows-only driver. And since it doesn't use an ISO-9660 file system, the only way to read data off of it is with a windows-only driver, too. So the thing is a paperweight unless one is using Windows. One can use the windows explorer to copy files into it, and one could use it to back up files if they're on a BSD machine shared by Samba. Useless for system recovery, but perhaps barely functional as a data backup. Live and learn. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 The only thing you can do easily is be wrong, and that's hardly worth the effort. -- Norton Juster ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Iomega REV drive, FreeBSD 4.11
I'm running FreeBSD 4.11. I last updated from STABLE in January: FreeBSD bogodyn.org 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Jan 22 13:10:32 MST 2005 [EMAIL PROTECTED]:/users2/obj/usr/src/sys/BOGODYN i386 I just purchased an external SCSI Iomga REV 35MB removable medium drive. I took the chance that since it was a SCSI device it would Just Work, since that has been my experience most of the time with SCSI devices and BSD. It doesn't. When I attach the device and camcontrol rescan all, I get this in the /var/log/messages: Jul 21 19:22:52 bogodyn /kernel: cd1 at ahc0 bus 0 target 5 lun 0 Jul 21 19:22:52 bogodyn /kernel: cd1: Iomega RRD 84.B Removable CD-ROM SCSI-4 device Jul 21 19:22:52 bogodyn /kernel: cd1: 20.000MB/s transfers (20.000MHz, offset 14 ) Jul 21 19:22:52 bogodyn /kernel: cd1: cd present [17090880 x 2048 byte records] That is, the drive is detected, but as a removable CDROM, not a direct access device. Does anyone have one of these things, and has anyone gotten it to work? Would updating to a more recent 4.11-STABLE be likely to get it right? I can't find anything in any of the FreeBSD-Questions archives that mentions this drive except for one from December, where someone asked if it worked and never got answered on-list. Pity to have such an expensive paperweight right now. Can anyone help? Does this thing work in FreeBSD 5.x? I have been avoiding upgrading to that. Ironically, getting the REV drive was part of a plan to start backing up my stuff so I could wipe the drive and install 5.x on a clean disk instead of having to deal with cleaning up 4.x mess --- I keep finding bits of cruft from the time I upgraded from 2.x... -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 The only thing you can do easily is be wrong, and that's hardly worth the effort. -- Norton Juster ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Answering my own question Re: Compile of GCC-3.4 port fails on FreeBSD 4.11 --- Help?
Answering my own question, just to get the answer into the archives. On Mon, Apr 25, 2005 at 10:20:38AM -0600, we recorded a bogon-computron collision of the [EMAIL PROTECTED] flavor, containing: I've been having trouble with ports on FreeBSD 4.11 lately, as more and more of them seem to want gcc 3.4 --- but I can't get gcc-3.4 to build. Turns out that the mingw port (gcc 2.95 cross-compiler for building windows binaries) is the culprit here. It installs a /usr/local/include/ansidecl.h file that is picked up by the configure of gcc-3.4, and that causes the problem. To figure that out I had to look for ATTRIBUTE_NONNULL on my spare linux box, found it in ansidecl.h, then hunted down why I had an ansidecl.h without ATTRIBUTE_NONNULL in it with pkg_info -W. Since I need the mingw port, I just temporarily moved ansidecl.h so gcc3.4 could build. Never Mind. Here's what I get when I attempt to make gcc 3.4: [...] In file included from insn-conditions.c:30: ../../gcc-3.4-20050128/gcc/output.h:122: syntax error before `ATTRIBUTE_NONNULL' In file included from insn-conditions.c:34: ../../gcc-3.4-20050128/gcc/toplev.h:57: syntax error before `ATTRIBUTE_NONNULL' [...] Has anyone else had a problem building gcc-3.4 on FreeBSD 4.11? I see nothing in the -questions or -ports archives about it, and google gave me nothing. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 The only thing you can do easily is be wrong, and that's hardly worth the effort. -- Norton Juster ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Compile of GCC-3.4 port fails on FreeBSD 4.11 --- Help?
I've been having trouble with ports on FreeBSD 4.11 lately, as more and more of them seem to want gcc 3.4 --- but I can't get gcc-3.4 to build. Here's what I get when I attempt to make gcc 3.4: [...] cc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I/usr/local/include -I. -I. -I.././..//gcc-3.4-20050128/gcc -I.././..//gcc-3.4-20050128/gcc/. -I.././..//gcc-3.4-20050128/gcc/../include insn-conditions.c In file included from insn-conditions.c:30: ../../gcc-3.4-20050128/gcc/output.h:122: syntax error before `ATTRIBUTE_NONNULL' In file included from insn-conditions.c:34: ../../gcc-3.4-20050128/gcc/toplev.h:57: syntax error before `ATTRIBUTE_NONNULL' ../../gcc-3.4-20050128/gcc/toplev.h:61: syntax error before `ATTRIBUTE_NONNULL' ../../gcc-3.4-20050128/gcc/toplev.h:65: syntax error before `ATTRIBUTE_NONNULL' ../../gcc-3.4-20050128/gcc/toplev.h:74: syntax error before `ATTRIBUTE_NONNULL' ../../gcc-3.4-20050128/gcc/toplev.h:75: syntax error before `ATTRIBUTE_NONNULL' gmake[2]: *** [insn-conditions.o] Error 1 gmake[2]: Leaving directory `/sandbox/ports/lang/gcc34/work/build/gcc' gmake[1]: *** [stage1_build] Error 2 gmake[1]: Leaving directory `/sandbox/ports/lang/gcc34/work/build/gcc' gmake: *** [bootstrap-lean] Error 2 *** Error code 2 Stop in /sandbox/ports/lang/gcc34. My system is FreeBSD 4.11-STABLE, last updated on 24 Jan, and my ports tree was last updated on 4 Feb. Prior to 24 Jan I had been running a much older FreeBSD 4.9. I only updated it then because I was hoping the update would fix this very same gcc-3.4 problem, and it didn't. Has anyone else had a problem building gcc-3.4 on FreeBSD 4.11? I see nothing in the -questions or -ports archives about it, and google gave me nothing. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 The only thing you can do easily is be wrong, and that's hardly worth the effort. -- Norton Juster ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
