[gentoo-amd64] Building vanilla gcc fails, any ideas?
Trying to build a gcc 4.3 snapshot (20080125) fails on my x86-64 box. While building libstdc++, I see many problems with various libc functions not being found, for instance gcc-4.3-20080125-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:140: error: '::ungetc' has not been declared I assume this has something to do with Gentoo's multilib header setup but I'm not sure what extra paths I should be configuring the build to search for. This snapshot is supposed to be stable (4.3 is in stage3 currently and from the reports on the mailing list is building well on other platforms). Currently I'm configuring with ../gcc-4.3-20080125/configure --enable-languages=c,c++,objc,obj-c++ --prefix=/usr/local/gcc-4.3-20080125 --program-suffix=-4.3-20080125 Any hints? Jack -- gentoo-amd64@lists.gentoo.org mailing list
Re: [gentoo-amd64] Playing DVD problems
On Wed, Nov 28, 2007 at 02:46:11PM +0100, Jean-Marc Hengen wrote: I personnaly prefer xine for DVD's, because it shows the dvd-menus and as far as I know, it's the only one who does this. Ogle also handles DVD menus Jack -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] iPod issue
On Mon, Oct 08, 2007 at 08:57:10AM -0400, Mark Haney wrote: Is this a new ipod? I read somewhere (Slashdot maybe?) that the new IPds have some sort of key that keeps any other app from using the ipod except for itunes. It's a simple checksum that has already been reverse engineered. I don't know about gtkpod, etc but I know gnupod can handle this as of 0.99.4 (http://www.gnu.org/software/gnupod/CHANGES) -Jack -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Local network backup
On Fri, Sep 14, 2007 at 03:34:06PM +0200, Jordi Molina wrote: It's not a big security risk, just ensure that the access of the user in the fw machine has restrictive access over its home and that it can't su/sudo to root. You can use something like scponly, to keep anyone who steals the key from getting shell access to your firewall: http://sublimation.org/scponly/wiki/index.php/Main_Page You could also limit where logins come from via AllowUsers in your sshd config. I had thought OpenSSH had some facility built in for limiting what particular users could do (so you could create an account that can only be used for sftp transfers, and sshd would not allow that user to get a tty or shell), but I can't seem to find anything about that in the man page, so I may just be imagining this feature. -Jack -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Local network backup
On Fri, Sep 14, 2007 at 05:32:14PM +0100, Mike Williams wrote: man sshd AUTHORIZED_KEYS FILE FORMAT Lots of interesting goodies. Thanks! I was almost certain I had used that a couple years back but couldn't find a mention of it anywhere in the ssh_config or sshd_config man pages so I was becoming doubtful of my memory. -Jack -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Anyone using i965 3D?
On Fri, Apr 06, 2007 at 02:27:46AM -0700, Andrei Slavoiu wrote: Do you have Xorg 7.2? The driver for this card was only included starting from this version, so if you use the current stable xorg you need to switch to the testing version. Yes, Xorg 7.2 with the 1.7.4 driver (actually the modesetting branch matching same, as I'm using an LCD and wanted 1680x1050 resolution support), Mesa 6.5.2 with 2.6.20.3 kernel With DRI off, glxgears/etc work though of course slowly. With them on, anything talking to gl fails, eg: (motoko ~)$ glxinfo name of display: :0.0 glxinfo: bufmgr_fake.c:746: bmGenBufferStatic: Assertion `0' failed. Aborted Backtrace shows the assertion inside i965_dri.so I also tried xorg-server-1.2.99.903.ebuild and xf86-video-i810-1.9.94, which failed entirely (segfault on driver load, trashed the display state and rendered the entire console unusable). Glad to know this is working for someone at least - so hopefully it's just something with my configuration or specific versions, or at the worst a hardware problem. Maybe DRI works under 4:3 screen layouts but not others? I can live with slow 3D, it's not essential to my workflow but it's very frustrating when your hardware doesn't seem to work as it should. -Jack -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Anyone using i965 3D?
Just wanted to ping the list to see if anyone using i965 embedded graphics was having any luck with 3d/DRI? Regardless of the driver, it seems that hardware 3d is completely non-functional on this chip under Linux. I've seen other people complain about the same problems I see in various forums, but (apparently) everything works fine for the driver developers, since I just get blank looks when I file bugs. Any input from Gentoo users? -Jack -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Quick Portage How to
On Wed, Mar 21, 2007 at 10:24:37PM +, Peter Humphrey wrote: On Wednesday 21 March 2007 18:45:39 Mark Haney wrote: Is there a way I can get portage to show me all the listed kernel sources I've installed? And one more they haven't mentioned: equery l gentoo-sources Another, related one that I use a lot is equery l sys-kernel/ (since I use a mix of gentoo-sources and vanilla-sources on my machines, depending on which contains fixes for the bugs that happen to be bothering me that day). -J -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Is swap need when there is 4g of ram?
On Tue, Mar 13, 2007 at 03:32:45PM +0100, Hemmann, Volker Armin wrote: 50mb in swap - and everything is slow. So slow as if every bit is fetched by a mule caravan. And it does not matter if it is a swap partition or a swap file. It is slow. But there is an easy way to get the box back to normal speed: swapoff -a swapon -a ... Perhaps better to tweak the VM so it is not as swap-happy using /proc/sys/vm/swappiness. See http://kerneltrap.org/node/1044 -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Another package that doesn't like GCC 4
On Wed, Nov 22, 2006 at 07:39:12PM +0100, Michael Weyersh?user wrote: Don't bother finding out which CFLAGS hurt gnupg. The ones posted above are about all that is supported by Gentoo. Anything else and you're on your own if stuff breaks. Such a bug report will most likely get closed as INVALID. I would think it would still be useful to have know, so the ebuild could use filter-flags to prevent this problem from occuring for others (if it is in fact a CFLAGS problem). -J -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: lets ask the other way round. Why should it speed up anything to have Xnumber of cores? Instead of a single thread per core, compiling happily, you have two or more competing for one core and regularly kick out each others data from the cache. To account for I/O wait states -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Mon, Nov 06, 2006 at 01:59:33PM +0100, Hemmann, Volker Armin wrote: On Monday 06 November 2006 13:49, Jack Lloyd wrote: On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: lets ask the other way round. Why should it speed up anything to have Xnumber of cores? Instead of a single thread per core, compiling happily, you have two or more competing for one core and regularly kick out each others data from the cache. To account for I/O wait states and how often does something wait for io and how often does some data is purged from the cache, because the other make instance is activated? When I switched from j2 to j1, compiling did not take any longer - but the box way much more usable. OK. shrug On my dual core machine, -j3 seems to be the sweet spot. Simply because something does not work for you does not mean it is going to be universally a bad idea. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] CFLAGS for Core2?
It is (a Gigabyte 965G-DS3). Initially I had problems with the loaded kernel not finding the SATA DVD drive. I switched the BIOS to use IDE instead of AHCI for the SATA ports and moved the DVD into the second SATA port (another driver bug that I saw described on LKML - seems the AHCI driver in 2.6.17 only sees the first two ports, which was indeed the case here). After emerging git-sources I was able to use all 4 ICH8 SATA ports (in AHCI mode) and was able to set up my RAID (I haven't tried to see if the 2 JMicron SATA ports or the single PATA port work or not - I don't need them right now, and I know support is OTW in any case). The Ethernet worked with the LiveCD kernel, which I hadn't expected (but saved me the trouble of throwing in a PCI NIC for the install). I haven't installed X yet, so I'm not sure how well (or if, for that matter) the new Intel embedded graphic cards work under free drivers. I will probably find that out tonight (the installer had no problem running the vesa driver for the display, so that works, at least). Also haven't tested Intel HD audio yet, I've heard people have been having problems with that with all but bleeding-edge ALSA. -Jack On Thu, Sep 21, 2006 at 08:53:10AM +0200, Nadav Horesh wrote: If the machine has the 965 chipset, there is a fair chance that you'll not be able to boot a 2006.1 CD (I least I couldn't). Please report you experience. Nadav. -Original Message- From: Jack Lloyd [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 22:25 To: gentoo-amd64@lists.gentoo.org Subject: [gentoo-amd64] CFLAGS for Core2? Tomorrow my new Core 2 workstation should be arriving, and reading through the 2006.1 amd64 install notes and so forth, the recomended CFLAGS for EM64T CPUs is -march=nocona. However as that is tuned for 64-bit enabled Netburst rather than Conroe, I'm wondering if anyone had thoughts on good flags. In particular as (to the extent that I know anything about microarchitecture), Conroe seems closer to a K8 than a P4, especially with regards to pipeline length and execution resources, I'm not sure that P4/Netburst tuning is the right thing to do. But the GCC docs say that -march=k8 enables 3dnow, which Intel chips don't have. So, right now the seems likely options would be: -march=k8 -mno-3dnow -msse3 -march=nocona -march=pentium-m -m64 [saw this suggested in the forums, seems like a bad idea] Or can I get away with just something like -mtune=k8 -msse3 (will this get me 64-bit code?) To be clear, my main goals here are a) enable generation of all instructions the CPU has, b) keep GCC from generating 3dnow,etc instructions, and c) get instruction scheduling that is at least moderately decent for the uarch I'm using. Since SSE/SSE2, -mfpmath=sse, and argument passing via registers are default in 64-bit mode, I suspect the only other options I might try are -momit-leaf-frame-pointer, -frename-registers, and -finline-functions. Ideas? -Jack -- gentoo-amd64@gentoo.org mailing list -- gentoo-amd64@gentoo.org mailing list -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] CFLAGS for Core2?
Tomorrow my new Core 2 workstation should be arriving, and reading through the 2006.1 amd64 install notes and so forth, the recomended CFLAGS for EM64T CPUs is -march=nocona. However as that is tuned for 64-bit enabled Netburst rather than Conroe, I'm wondering if anyone had thoughts on good flags. In particular as (to the extent that I know anything about microarchitecture), Conroe seems closer to a K8 than a P4, especially with regards to pipeline length and execution resources, I'm not sure that P4/Netburst tuning is the right thing to do. But the GCC docs say that -march=k8 enables 3dnow, which Intel chips don't have. So, right now the seems likely options would be: -march=k8 -mno-3dnow -msse3 -march=nocona -march=pentium-m -m64 [saw this suggested in the forums, seems like a bad idea] Or can I get away with just something like -mtune=k8 -msse3 (will this get me 64-bit code?) To be clear, my main goals here are a) enable generation of all instructions the CPU has, b) keep GCC from generating 3dnow,etc instructions, and c) get instruction scheduling that is at least moderately decent for the uarch I'm using. Since SSE/SSE2, -mfpmath=sse, and argument passing via registers are default in 64-bit mode, I suspect the only other options I might try are -momit-leaf-frame-pointer, -frename-registers, and -finline-functions. Ideas? -Jack -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] CFLAGS for Core2?
On Wed, Sep 20, 2006 at 10:34:30PM +0200, Simon Stelling wrote: Jack Lloyd wrote: -march=k8 -mno-3dnow -msse3 This is safe. -march=nocona This is also safe. OK, thank you. I'll probably try both variations and see what kind performance difference (if any) results. -march=pentium-m -m64 [saw this suggested in the forums, seems like a bad idea] This is stupid. That was pretty much my impression as well. :) -Jack -- gentoo-amd64@gentoo.org mailing list
