Re: [gentoo-amd64] Weird and unpredictable problem: emerge grinds system to a halt
Petter Haggholm wrote: > The subject is fairly descriptive. Often -- but not always -- an > emerge will render my system unusable. At a PORTAGE_NICENESS of 3, and > fairly standard MAKEOPTS of "-j2" (on a single-core system), I'm ... > well, rather surprised, confused, and very frustrated. I also can't be > very specific, because I have no real idea of what's causing this, and > the symptoms are very general: The system becomes unresponsive, the > mouse will move but with enough of a lag that physically moving it may > not cause a cursor movement for the next 30 seconds or so, clicking a > taskbar window may not have an effect at all; sometimes I can't even > ssh into the system from my other computer (to kill the emerge) > because it's slow enough that the ssh daemon times out my login > attempt. This never used to happen, I'm not aware of using any weird > settings, I recently rebuilt my entire system with conservative CFLAGS > (-march=athlon64 -O2 -pipe -fomit-frame-pointer), and I have an x86 > (pentium-m) system with very, very similar settings that exhibits no > such problems. > > Any hints, thoughts, or suggestions would be very much welcomed. > System info follows. > 1) Does the system go out from this state after some time or you have to cold reset it? 2) What happens if you put PORTAGE_NICENESS=19, MAKEOPTS of "-j2 -l1" ? l5 (small "L", not the number "one"), means "loadavg=<1" If loadavg goes up to 1 make waits this level to drop before continuing its job 3) Is DMA enabled for your HDD(s)? (hdparm -d1 /dev/xxx)? 4) Have you done any overclocking? -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Weird and unpredictable problem: emerge grinds system to a halt
Dnia czwartek, 28 września 2006 07:58, Petter Haggholm napisał: > Portage 2.1.2_pre1-r3 (default-linux/amd64/2006.1, gcc-4.1.1, > standard MAKEOPTS of "-j2" (on a single-core system), I'm ... well, > iproute2 ipv6 isdnlog jabber jpeg kdeenablefinal kernel_linux libg++ I had this, too. On single-core -j2 + kdeenablefinal + gcc-4 puts system down to its knees. Put '-j2' away and it should fix it. It has no sense anyway, if you have no multicore or don't use distcc... -- Pawel Kraszewski www.kraszewscy.net -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] How To Play WMV?
Boyd Stephen Smith Jr. wrote: > On Wednesday 27 September 2006 21:55, Peter Davoust <[EMAIL PROTECTED]> > TOP-POSTED about 'Re: [gentoo-amd64] How To Play WMV?': > >> On Wed, 2006-09-27 at 19:29 -0500, Boyd Stephen Smith Jr. wrote: >> >>> On Wednesday 27 September 2006 06:25, "Christoph Mende" >>> <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] How To Play >>> WMV?': >>> Latest stable version of ffmpeg is supposed to support wmv. >>> Yeah, I don't have any -bin packages installed on ~amd64 and I can >>> play some WMVs. >>> >> There are different versions of wmv. Last time I checked (on Ubuntu >> atleast), the 64 bit of the w32codecs didn't work for WMV 9. The 32 bit >> one seems to work perfectly though. You also have to have 32-bit >> mplayer. >> > > Please don't top-post. > > Yeah, it really doesn't matter to me when proprietary formats aren't > available. When I moved to amd64, I happily shed both flash and WMVs. > (At the time I don't believe either firefox-bin or mplayer-bin was > available.) I figure if it's not important enough for the > producer/distributor to use accessible formats (Speex, Vorbis, FLAC, > Theora, etc.) it's not important enough for me to spend time watching. > > *Insert Duncan's .sig here* > > Well, I'm sorry but I disagree. Let's not go fanatic about any ideas. Free software and open source are the greatest thing in the IT world (my personal opinion), but should I not use NVidia's drivers only because they are not GPLed? I would say anyone who uses software emulation instead of hardware acceleration only because of the license is a fanatic. I noticed that there is some kind of flash application that becomes more and more popular on sites [1] providing something like "funny clips exchange service". In order to watch the clips one needs Flash Player. AFAIK there is no Flash Player for amd64 and there is no Flash-8 for linux. No doubt it is wrong, but I'm far from the idea that the clips people send are not worth seeing because of technical or license issues. So I want to have flash/wmv/whatever running under Gentoo instead of depriving myself. [1] http://www.metacafe.com/ -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 22:59, Daniel Iliev <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] First Impressions': > Dan Pasanen wrote: > > Ok, im not too sure about this, but i was wondering, i have dual core > > turion64's should that affect if im running -O2 or -O3? currently im > > running -O2. and if i did change it to -O3, what, if anything should > > i recompile? Dual core or not won't affect your CFLAGS much. Worry mostly about the size of your L1 cache, compared to processors of the same architecture being sold today. If yours is fairly large, go with -O3; If undersized, go with -Os; Otherwise, -O2 will serve you well. > I thing it is reasonable to doubt that a program compiled with > "-O3" would greatly outperform the same program compiled with "-O2". This is a reasonable doubt, for reasons already mentioned. > The > same logic is applicable about stability. I have to admit that my logic > here is a plain arithmetic of type: "1 lemon - 10 cents, 10 lemons - 100 > cents". Well, optimization techniques are quite a bit more varied than lemons. In particular, if you could only choose one optimization technique from the gcc info pages there is probably a "correct" choice that 90% of the gcc developers would agree on. And guess what? They probably put that one in -O1. :) By the time you get to -O3, you are really just instructing the compiler on what tradeoffs to make. finline-functions and funswitch-loops are code size vs. execution path length tradeoffs and fgcse-after-reload is a [lots of] compilation time vs. [a little] (code size AND execution path length) tradeoff. Again, the performance gained (or lost) from a given compiler optimization option can vary based on program and processor. If you don't feel you can make a good decision based on reading the gcc info pages, don't include the option in your CFLAGS and just go with -O2 or -O3. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgpCkymir915i.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
On Thursday 28 September 2006 02:26, Boyd Stephen Smith Jr. wrote: > On Wednesday 27 September 2006 17:40, "Hemmann, Volker Armin" > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] > > First Impressions': > > On Thursday 28 September 2006 00:03, Boyd Stephen Smith Jr. wrote: > > > I also like: > > > funit-at-a-time, funswitch-loops, and fprefetch-loop-arrays > > > > not with 512kb cache ;) > > Do you not have separate D and I caches? Cause fprefetch-loop-arrays won't > hurt your I cache. I am talking about L2 cache. L1 has that destinction, L2 not ;) -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
On 9/27/06, Daniel Iliev <[EMAIL PROTECTED]> wrote: I don't think someone would really file a bug report for this It's true that my OCD about optimizing becomes painful when I see my flags overruled but I (still) can control myself ;-) Your cflags really aren't going to change much. It's better to stick with something that's been tested by a large number of people and is known to be safe. For instance, consider the 3rd post in this forum thread [1]. Even with an application like povray which is highly math and CPU driven tossing in all kinds of crazy cflags only results in a maximum of 0.05s (1.7%) improvement over the baseline -O2 -march settings, and that sort of difference in times is almost certainly within the margin of error. Most of the cflags (including -O3) actually decreased performance. [1] http://forums.gentoo.org/viewtopic.php?p=613970 -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Weird and unpredictable problem: emerge grinds system to a halt
The subject is fairly descriptive. Often -- but not always -- an emerge will render my system unusable. At a PORTAGE_NICENESS of 3, and fairly standard MAKEOPTS of "-j2" (on a single-core system), I'm ... well, rather surprised, confused, and very frustrated. I also can't be very specific, because I have no real idea of what's causing this, and the symptoms are very general: The system becomes unresponsive, the mouse will move but with enough of a lag that physically moving it may not cause a cursor movement for the next 30 seconds or so, clicking a taskbar window may not have an effect at all; sometimes I can't even ssh into the system from my other computer (to kill the emerge) because it's slow enough that the ssh daemon times out my login attempt. This never used to happen, I'm not aware of using any weird settings, I recently rebuilt my entire system with conservative CFLAGS (-march=athlon64 -O2 -pipe -fomit-frame-pointer), and I have an x86 (pentium-m) system with very, very similar settings that exhibits no such problems. Any hints, thoughts, or suggestions would be very much welcomed. System info follows. -- Petter Häggholm -- dreadfort ~ # emerge --info Portage 2.1.2_pre1-r3 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r7 x86_64) = System uname: 2.6.17-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.5 Last Sync: Wed, 27 Sep 2006 14:30:09 + ccache version 2.4 [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 dev-util/confcache: [Not Present] sys-apps/sandbox:1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.cites.uiuc.edu/pub/gentoo http://prometheus.cs.wmich.edu/gentoo http://gentoo.chem.wisc.edu/gentoo/ http://mirror.espri.arizona.edu/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://distfiles.gentoo.org"; LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/liferea_overlay /usr/portage/local/layman/petter-haggholm" SYNC="rsync://castleblack/gentoo-portage" USE="amd64 7zip X a52 aac acpi aim alsa amr apache2 artworkextra avahi bash-completion beagle berkdb bitmap-fonts branding bzip2 cairo cdinstall cdrom cli crypt cscope cups cursors daap dba dbus divx dlloader doc dri dts dvd dvi editor eds elibc_glibc encode fam ffmpeg firefox flac foomaticdb fortran gcc64 gcj gdbm gdm gif gimp gimpprint glibc-omitfp glitz gmail gmailtimestamps gmedia gnome gnome-print gnuplot gnutls gphoto2 gpm gstreamer gstreamer010 gtalk gtk gtk2 gtkhtml hal howl-compat icons icq id3 imlib initng_plugins_also initng_plugins_bash_launcher initng_plugins_chdir initng_plugins_chroot initng_plugins_conflict initng_plugins_cpout initng_plugins_critical initng_plugins_cron initng_plugins_daemon initng_plugins_dev initng_plugins_dllaunch initng_plugins_envparser initng_plugins_find initng_plugins_fstat initng_plugins_history initng_plugins_idleprobe initng_plugins_initctl initng_plugins_interactive initng_plugins_iparser initng_plugins_last initng_plugins_limit initng_plugins_logfile initng_plugins_netprobe initng_plugins_ngc4 initng_plugins_pause initng_plugins_pidfile initng_plugins_reload initng_plugins_renice initng_plugins_rlparser initng_plugins_simple_launcher initng_plugins_stcmd initng_plugins_stdout initng_plugins_suid initng_plugins_syncron initng_plugins_syslog initng_plugins_unneeded input_devices_evdev input_devices_keyboard input_devices_mouse ipod iproute2 ipv6 isdnlog jabber jpeg kdeenablefinal kernel_linux libg++ libnotify linguas_en lm_sensors logitech-mouse logrotate mad math mdnsresponder-compat mikmod modplu
Re: [gentoo-amd64] First Impressions
Boyd Stephen Smith Jr. wrote: > On Wednesday 27 September 2006 19:56, Daniel Iliev <[EMAIL PROTECTED]> > wrote about 'Re: [gentoo-amd64] First Impressions': > >> Boyd Stephen Smith Jr. wrote: >> >>> On Wednesday 27 September 2006 11:11, "Hemmann, Volker Armin" >>> <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] >>> >>> First Impressions': >>> -O3 don't do it. O2 is much, much safer and not really slower. It will prevent a lot of breakage. >>> -O3 breaking just doesn't happen anymore. >>> Also, some applications break with just -O2. >>> Now, it is an open question whether -O3 is significantly faster than >>> -O2. My >>> recommendation is -O3. :) >>> >> I've always used "-O3". >> I think I've read somewhere in *.gentoo.org that It should be reported >> if a "testing" version works fine so it could get in the stable tree >> faster. >> > > Please only file a stabilization bug if (a) there are no open bug reports > on the version you want stabilized (b) all dependencies of the that > version can be satisfied with stable packages on the ARCH you want > stabilized AND (c) at least 30 days have passed since the ebuild for that > version has been modified. > > There has to be some time between an ebuild being available and it becoming > stable to test on setups that aren't exactly like yours. I know (some) > people want things declared stable ASAP, but declaring a package stable > doesn't make it so and there are (many, many) people that want stable > Gentoo to actually be stable. E.g. they do real work on the system. :P > > >> Should this "replace-flags" stuff be reported when the package >> compiles successfully with "-O3"? >> > > I fear you may find such bugs closed as WONTFIX/INVALID fairly quickly, > especially if you started reporting en masse. That said, if you have a > compelling reason to use -O3 instead of what it is replaced with (not > just "it works for me") for a specific package, I'd say file the bug, but > be sure to include the reason(s) the replacement doesn't work for you. > > But of course! ;-) I was just thinking if it would be theoretically right to classify the use of "replace-flags" as a bug if it is not needed (and also not harming). I don't think someone would really file a bug report for this It's true that my OCD about optimizing becomes painful when I see my flags overruled but I (still) can control myself ;-) The thing I like most in Gentoo is that it gives many choices while its maintenance still remains automated. If I wanted to choose and manually change everything and everywhere I'd rather build myself an LFS [1] system. [1] http://www.linuxfromscratch.org/ -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] How To Play WMV?
On Wednesday 27 September 2006 21:55, Peter Davoust <[EMAIL PROTECTED]> TOP-POSTED about 'Re: [gentoo-amd64] How To Play WMV?': > On Wed, 2006-09-27 at 19:29 -0500, Boyd Stephen Smith Jr. wrote: > > On Wednesday 27 September 2006 06:25, "Christoph Mende" > > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] How To Play > > WMV?': > > > Latest stable version of ffmpeg is supposed to support wmv. > > Yeah, I don't have any -bin packages installed on ~amd64 and I can > > play some WMVs. > There are different versions of wmv. Last time I checked (on Ubuntu > atleast), the 64 bit of the w32codecs didn't work for WMV 9. The 32 bit > one seems to work perfectly though. You also have to have 32-bit > mplayer. Please don't top-post. Yeah, it really doesn't matter to me when proprietary formats aren't available. When I moved to amd64, I happily shed both flash and WMVs. (At the time I don't believe either firefox-bin or mplayer-bin was available.) I figure if it's not important enough for the producer/distributor to use accessible formats (Speex, Vorbis, FLAC, Theora, etc.) it's not important enough for me to spend time watching. *Insert Duncan's .sig here* -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgpMhO3wI64Zm.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
Dan Pasanen wrote: > Ok, im not too sure about this, but i was wondering, i have dual core > turion64's should that affect if im running -O2 or -O3? currently im > running -O2. and if i did change it to -O3, what, if anything should > i recompile? >From gcc man page: -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options. So "-O3" is adding 3 more optimization flags to the bunch of flags "-O2" brings. I thing it is reasonable to doubt that a program compiled with "-O3" would greatly outperform the same program compiled with "-O2". The same logic is applicable about stability. I have to admit that my logic here is a plain arithmetic of type: "1 lemon - 10 cents, 10 lemons - 100 cents". There are programmers here who's opinion should be respected if it differs from this logic. -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Ok, im not too sure about this, but i was wondering, i have dual core turion64's should that affect if im running -O2 or -O3? currently im running -O2. and if i did change it to -O3, what, if anything should i recompile? On 9/27/06, Boyd Stephen Smith Jr. <[EMAIL PROTECTED]> wrote: On Wednesday 27 September 2006 19:56, Daniel Iliev <[EMAIL PROTECTED]>wrote about 'Re: [gentoo-amd64] First Impressions':> Boyd Stephen Smith Jr. wrote:> > On Wednesday 27 September 2006 11:11, "Hemmann, Volker Armin" > > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64]> >> > First Impressions':> >> -O3 don't do it. O2 is much, much safer and not really slower. It > >> will prevent a lot of breakage.> > -O3 breaking just doesn't happen anymore.> > Also, some applications break with just -O2.> > Now, it is an open question whether -O3 is significantly faster than > > -O2. My> > recommendation is -O3. :)> I've always used "-O3".> I think I've read somewhere in *.gentoo.org that It should be reported> if a "testing" version works fine so it could get in the stable tree > faster.Please only file a stabilization bug if (a) there are no open bug reportson the version you want stabilized (b) all dependencies of the thatversion can be satisfied with stable packages on the ARCH you want stabilized AND (c) at least 30 days have passed since the ebuild for thatversion has been modified.There has to be some time between an ebuild being available and it becomingstable to test on setups that aren't exactly like yours. I know (some) people want things declared stable ASAP, but declaring a package stabledoesn't make it so and there are (many, many) people that want stableGentoo to actually be stable. E.g. they do real work on the system. :P > Should this "replace-flags" stuff be reported when the package> compiles successfully with "-O3"?I fear you may find such bugs closed as WONTFIX/INVALID fairly quickly,especially if you started reporting en masse. That said, if you have a compelling reason to use -O3 instead of what it is replaced with (notjust "it works for me") for a specific package, I'd say file the bug, butbe sure to include the reason(s) the replacement doesn't work for you. --"If there's one thing we've established over the years,it's that the vast majority of our users don't have the slightestclue what's best for them in terms of package stability."-- Gentoo Developer Ciaran McCreesh
Re: [gentoo-amd64] PDF Editor
Hello All, Can anyone recommend an application to edit a pdf file, and of course works on 64 bit Gentoo? Thanks, Sean * app-text/pdftk Latest version available: 1.12 Latest version installed: [ Not Installed ]< just about to Size of downloaded files: 2,310 kB Homepage:http://www.accesspdf.com/pdftk Description: A tool for manipulating PDF documents License: GPL-2 website says; If PDF is electronic paper, then pdftk is an electronic staple-remover, hole-punch, binder, secret-decoder-ring, and X-Ray-glasses. Pdftk is a command-line tool for doing everyday things with PDF documents. Keep one in the top drawer of your desktop and use it to: * Merge PDF Documents * Split PDF Pages into a New Document * Decrypt Input as Necessary (Password Required) * Encrypt Output as Desired * Fill PDF Forms with FDF Data and/or Flatten Forms * Apply a Background Watermark * Report on PDF Metrics such as Metadata, Bookmarks, and Page Labels * Update PDF Metadata * Attach Files to PDF Pages or the PDF Document * Unpack PDF Attachments * Burst a PDF Document into Single Pages * Uncompress and Re-Compress Page Streams * Repair Corrupted PDF (Where Possible) Pdftk allows you to manipulate PDF easily and freely. It does not require Acrobat, and it runs on Windows, Linux, Mac OS X, FreeBSD and Solaris. Pdftk is free software (GPL). I'll let you know how I find it as I too have been trying for some time to find a friendly way of editing PDF files... BTW, GIMP can do this, but is not really for tool for the job. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] How To Play WMV?
There are different versions of wmv. Last time I checked (on Ubuntu atleast), the 64 bit of the w32codecs didn't work for WMV 9. The 32 bit one seems to work perfectly though. You also have to have 32-bit mplayer. -Peter On Wed, 2006-09-27 at 19:29 -0500, Boyd Stephen Smith Jr. wrote: > On Wednesday 27 September 2006 06:25, "Christoph Mende" > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] How To Play > WMV?': > > Latest stable version of ffmpeg is supposed to support wmv (at least > > ffmpeg-0.4.9_p20060816 has working wmv for me here), which is imho a > > better solution. > > Yeah, I don't have any -bin packages installed on ~amd64 and I can play > some WMVs. Others either do not play, or play audio only. > -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 19:56, Daniel Iliev <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] First Impressions': > Boyd Stephen Smith Jr. wrote: > > On Wednesday 27 September 2006 11:11, "Hemmann, Volker Armin" > > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] > > > > First Impressions': > >> -O3 don't do it. O2 is much, much safer and not really slower. It > >> will prevent a lot of breakage. > > -O3 breaking just doesn't happen anymore. > > Also, some applications break with just -O2. > > Now, it is an open question whether -O3 is significantly faster than > > -O2. My > > recommendation is -O3. :) > I've always used "-O3". > I think I've read somewhere in *.gentoo.org that It should be reported > if a "testing" version works fine so it could get in the stable tree > faster. Please only file a stabilization bug if (a) there are no open bug reports on the version you want stabilized (b) all dependencies of the that version can be satisfied with stable packages on the ARCH you want stabilized AND (c) at least 30 days have passed since the ebuild for that version has been modified. There has to be some time between an ebuild being available and it becoming stable to test on setups that aren't exactly like yours. I know (some) people want things declared stable ASAP, but declaring a package stable doesn't make it so and there are (many, many) people that want stable Gentoo to actually be stable. E.g. they do real work on the system. :P > Should this "replace-flags" stuff be reported when the package > compiles successfully with "-O3"? I fear you may find such bugs closed as WONTFIX/INVALID fairly quickly, especially if you started reporting en masse. That said, if you have a compelling reason to use -O3 instead of what it is replaced with (not just "it works for me") for a specific package, I'd say file the bug, but be sure to include the reason(s) the replacement doesn't work for you. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgpUnui5WE2E8.pgp Description: PGP signature
Re: [gentoo-amd64] Creation of locales
Peter Humphrey wrote: > All right, hands up! Which package deletes all locales off the system when > it's emerged? Locale-gen doesn't work on this box, and the glibc creation > of locales that was supposed to work never has either, so I've been using > localedef to create them as described in the localisation guide. > > But every time I have a major reinstallation of packages, eventually I > notice perl packages complaining of missing locales. So where are they > going? I need to know this so that I can redefine them before continuing > the emerge. > > In addition to Mr.Andresen' reply. There is a package that deletes the unnecessary locales: eix localepurge * app-admin/localepurge Available versions: 0.5.1 ~0.5.2 Installed: none Homepage: http://www.josealberto.org/blog/index.php?s=localepurge Description: Script to recover diskspace wasted for unneeded locale files and localized man pages. -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
"Boyd Stephen Smith Jr." <[EMAIL PROTECTED]> skribis: > Well, I actually include them for when my -O3 is changed (by the ebuild) > to -O2 or lower. >:) That works for me. I personally don’t worry much about optimizations unless I am working on something that’s essentially assembly code, where I need the compiler to generate a specific sort of code. Then I play with optimizations to see what code gets generated. This has happened once with amd64, when I wrote coexpression support for amd64 in the Unicon language. (It’s a very tiny bit of code.) -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgphhm9E6Y2ID.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
Boyd Stephen Smith Jr. wrote: > On Wednesday 27 September 2006 11:11, "Hemmann, Volker Armin" > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] > First Impressions': > >> -O3 don't do it. O2 is much, much safer and not really slower. It will >> prevent a lot of breakage. >> > > Bah! > > -O3 breaking just doesn't happen anymore. I'm been running it for years. > In fact -O3 has never generated invalid code [1] on x86 or amd64 > platforms. It did for a period of time on ppc, but I think that was like > 10 years ago. > > Also, some applications break with just -O2. I count 8 ebuilds that > replace this cflag specifically, there could be others that filter it or > filter/replace optimization options entirely. My methodology is available > on request. > > Now, it is an open question whether -O3 is significantly faster than -O2 > and depending on a number of factors it may actually be slower. -O3 will > enlarge code to make execution paths shorter, but a cache miss is probably > goes to blow away any advantage gained. Conversely, -Os will make > execution paths longer to shrink code, and a cache hits may make up for > the longer path. [2] > > So, which is best depends on the program and on the CPU used (not only > instruction set, but also cache sizes). Therefore, making a sweeping > recommendations is not recommended, but that doesn't stop anyone. My > recommendation is -O3. :) > > Naturally, Gentoo wins over binary distros on this point, since you can use > CFLAGS that are appropriate for your specific processor (including cflags > which control the optimization tradeoff parameters) as well as tuning for > the specific application. > > I've always used "-O3". The only exception is busybox, when I compile it for initrd/initramfs. In those cases I prefer "-Os". I've never seen a package which explodes with "-O3" and compiles with "-O2". That's the reason I hate to find that "replace-flags -O? -O2" stuff in the ebuilds. I think I've read somewhere in *.gentoo.org that It should be reported if a "testing" version works fine so it could get in the stable tree faster. Should this "replace-flags" stuff be reported when the package compiles successfully with "-O3"? -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] How To Play WMV?
On Wednesday 27 September 2006 06:25, "Christoph Mende" <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] How To Play WMV?': > Latest stable version of ffmpeg is supposed to support wmv (at least > ffmpeg-0.4.9_p20060816 has working wmv for me here), which is imho a > better solution. Yeah, I don't have any -bin packages installed on ~amd64 and I can play some WMVs. Others either do not play, or play audio only. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgpiUfifB15sK.pgp Description: PGP signature
Re: [gentoo-amd64] [OT] Filesharing client
On Wednesday 27 September 2006 10:11, "Mark Haney" <[EMAIL PROTECTED]> wrote about '[gentoo-amd64] [OT] Filesharing client': > Relatively stupid question, but since I can no longer compile > gtk-gnutella on my box here (and I haven't had time to look at the > problem just yet), is there another good P2P client that runs on amd64? > I'd like to have access to fasttrack and gnutella networks if possible. > I am not much for spending a ton of time configuring, but I will if i > need to. Apollon is a multi-network (including FT and gnutella) P2P application for KDE, based on giFT, IIRC, that works, although it does take a bit of configuration. Well, you are really configuring giFT, but it still has to be done before you are sharing. If you prefer GTK+ (over QT/KDE), giFT has two fortends in portage: giftoxic and giftui. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgp7zYti7EGBD.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 18:25, [EMAIL PROTECTED] wrote about 'Re: [gentoo-amd64] First Impressions': > unit-at-a-time and (I believe) prefetch-loop-arrays are enabled by -O2 > unswitch-loops is included in -O3 Well, I actually include them for when my -O3 is changed (by the ebuild) to -O2 or lower. >:) -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgpVy65FwOIFz.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 17:40, "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] First Impressions': > On Thursday 28 September 2006 00:03, Boyd Stephen Smith Jr. wrote: > > I also like: > > funit-at-a-time, funswitch-loops, and fprefetch-loop-arrays > > not with 512kb cache ;) Do you not have separate D and I caches? Cause fprefetch-loop-arrays won't hurt your I cache. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgp358rbgwE9C.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
"Boyd Stephen Smith Jr." <[EMAIL PROTECTED]> skribis: > I also like: > funit-at-a-time, funswitch-loops, and fprefetch-loop-arrays unit-at-a-time and (I believe) prefetch-loop-arrays are enabled by -O2 unswitch-loops is included in -O3 -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpo7IFPSUtuo.pgp Description: PGP signature
Re: [gentoo-amd64] Creation of locales
On Thursday 28 September 2006 00:08, Peter Humphrey wrote: > All right, hands up! Which package deletes all locales off the system when > it's emerged? Locale-gen doesn't work on this box, and the glibc creation > of locales that was supposed to work never has either, so I've been using > localedef to create them as described in the localisation guide. > > But every time I have a major reinstallation of packages, eventually I > notice perl packages complaining of missing locales. So where are they > going? I need to know this so that I can redefine them before continuing > the emerge. `locale-gen --config /etc/locale.gen` is run by pkg_postinst() of sys-libs/glibc. What is the output of: # egrep -v '^#|^$' /etc/locale.gen -- Bo Andresen pgp6yybHwfOUB.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
On Thursday 28 September 2006 00:03, Boyd Stephen Smith Jr. wrote: > On Wednesday 27 September 2006 13:52, "Hemmann, Volker Armin" > <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] > > First Impressions': > > frename-registers, > > I have it, it's good especially for 64-bit code where we have a lot of > registers. > > > fweb > > Ditto. > > > ftracer. > > I use it and... I too, but it is known to make trouble ;) > > > But don't complain, if > > something does not built > > I'm having no (compiler-related) problems so far, even on ~amd64. try freeciv ;) > > I also like: > funit-at-a-time, funswitch-loops, and fprefetch-loop-arrays not with 512kb cache ;) Maybe, if I had more... -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Creation of locales
All right, hands up! Which package deletes all locales off the system when it's emerged? Locale-gen doesn't work on this box, and the glibc creation of locales that was supposed to work never has either, so I've been using localedef to create them as described in the localisation guide. But every time I have a major reinstallation of packages, eventually I notice perl packages complaining of missing locales. So where are they going? I need to know this so that I can redefine them before continuing the emerge. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 13:52, "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] First Impressions': > frename-registers, I have it, it's good especially for 64-bit code where we have a lot of registers. > fweb Ditto. > ftracer. I use it and... > But don't complain, if > something does not built I'm having no (compiler-related) problems so far, even on ~amd64. I also like: funit-at-a-time, funswitch-loops, and fprefetch-loop-arrays -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh pgp0gK8oZkCar.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 11:11, "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-amd64] First Impressions': > -O3 don't do it. O2 is much, much safer and not really slower. It will > prevent a lot of breakage. Bah! -O3 breaking just doesn't happen anymore. I'm been running it for years. In fact -O3 has never generated invalid code [1] on x86 or amd64 platforms. It did for a period of time on ppc, but I think that was like 10 years ago. Also, some applications break with just -O2. I count 8 ebuilds that replace this cflag specifically, there could be others that filter it or filter/replace optimization options entirely. My methodology is available on request. Now, it is an open question whether -O3 is significantly faster than -O2 and depending on a number of factors it may actually be slower. -O3 will enlarge code to make execution paths shorter, but a cache miss is probably goes to blow away any advantage gained. Conversely, -Os will make execution paths longer to shrink code, and a cache hits may make up for the longer path. [2] So, which is best depends on the program and on the CPU used (not only instruction set, but also cache sizes). Therefore, making a sweeping recommendations is not recommended, but that doesn't stop anyone. My recommendation is -O3. :) Naturally, Gentoo wins over binary distros on this point, since you can use CFLAGS that are appropriate for your specific processor (including cflags which control the optimization tradeoff parameters) as well as tuning for the specific application. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh [1] That doesn't mean there weren't programs that crashed when compiled under -O3, just that the deficiency was found to be with the program not the compiler. [2] But -Os may also break programs, and I've heard more problems on -Os than -O3 recently. -Os had also had times when it generates invalid code. pgpkxoqnWp9Ns.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
hi, On Wednesday 27 September 2006 19:35, Daniel Iliev wrote: > > > > Don't use that flags. They are bad for amd64. Trust the devs, they know > > better than you or me. > > Thank you very much for this reply. I'll follow your advise and remove > the redundant flags. > About trusting the devs - well, it depends. I trust them 100% if I need > a rock stable system. In that case I would not dare to divert from any > of the official instructions. > BUT. Devs always tent to advertise the safest ways - this brings users > no/less headaches and therefore less bug-reports ;-) > My case however is slightly different - I'm talking about my home > desktop which is dedicated for experiments and fun. So I'm not afraid to > break the system here and rebuild it again. In this particular moment my > purpose is to get the most out of the hardware no matter the stability. > So I'll leave -O3 ;-) if you really want to be adventurous, try frename-registers, fpeel-loops, fweb or ftree-vectorize. Or ftracer. But don't complain, if something does not built (I have a set of save flags, just to be able to build freeciv. With my stupid standard flags, gcc will ICE) > > BTW, Everyone, > I'm observing something very interesting: > I was told not to go gentoo-amd64 for it was not stable. I was told not > to migrate because there were still many important programs pending to > be ported. I read almost everywhere about headaches and breakages. > Reading your replies in this thread also suggests strictly following the > official way otherwise - problems. > It is very strange - I was ready to meet tons of major problems but I > haven't met a single one yet. It is my opinion that the possibility of > problems on gentoo-amd64 is highly overrated. I installed it with no > problems, I obviously have tweaked it a lot beyond normal and what I see > is a perfectly working system. It appears that gentoo-amd64 team along > with the GNU, linux-kernel and all other nice guys who provide free/open > source software have done a great work and we owe them BIG THANKS. I > just wonder how come that so many people talk about some non-existing > problems. > How come that still in my first try I have bootstrapped from stage3, > made "emerge -e system", installed xfce4, gnome, firefox, thunderbird, > and a bunch of other packages along with all their dependencies, then > made "emerge -e world" and after all this compiling I had to do "emerge > --resume" only once when some package wanted mysql build with -fpic > flag. I'm I lucky or what? ;-) > maybe. When I switched from gcc3 to gcc4 I had to -e world.. and from the hundreds of packages 14 broke. 10 of them package.masked. The problem: people with problems are very vocal, while the users without probs are silent. So will see always lots of complaints, but almost never success stories. I have not any more problems with my ~amd64 system than I had with my ~x86 system. I would even postulate, that I have seen less breakage on ~amd64. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 12:35, Daniel Iliev wrote: ...snip > BTW, Everyone, > I'm observing something very interesting: > I was told not to go gentoo-amd64 for it was not stable. I was told not > to migrate because there were still many important programs pending to > be ported. I read almost everywhere about headaches and breakages. > Reading your replies in this thread also suggests strictly following the > official way otherwise - problems. > It is very strange - I was ready to meet tons of major problems but I > haven't met a single one yet. It is my opinion that the possibility of > problems on gentoo-amd64 is highly overrated. I installed it with no > problems, I obviously have tweaked it a lot beyond normal and what I see > is a perfectly working system. It appears that gentoo-amd64 team along > with the GNU, linux-kernel and all other nice guys who provide free/open > source software have done a great work and we owe them BIG THANKS. I > just wonder how come that so many people talk about some non-existing > problems. > How come that still in my first try I have bootstrapped from stage3, > made "emerge -e system", installed xfce4, gnome, firefox, thunderbird, > and a bunch of other packages along with all their dependencies, then > made "emerge -e world" and after all this compiling I had to do "emerge > --resume" only once when some package wanted mysql build with -fpic > flag. I'm I lucky or what? ;-) > > > -- > Best regards, > Daniel Somebody misinformed you. Gentoo-amd64 rulez, the rest drule! ;-) I run the unstable (~amd64) branch, and even that is rock solid. Sure it breaks now and then, but that's why they call it unstable. Your success with your first build is a testament to the great community we have here. Welcome aboard! glide -- Mike Bonar -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Daniel Iliev <[EMAIL PROTECTED]> skribis: > How come that still in my first try I have bootstrapped from stage3, > made "emerge -e system", installed xfce4, gnome, firefox, thunderbird, > and a bunch of other packages along with all their dependencies, then > made "emerge -e world" and after all this compiling I had to do "emerge > --resume" only once when some package wanted mysql build with -fpic > flag. I'm I lucky or what? ;-) Probably. :) I’m also a home user and have broken my system repeatedly. If I’m not breaking my system, it’s because I’m busy with some other fun. Back when I was playing with PaX and Gentoo was less mature, I did sometimes ‘have to’ put flags of that sort in to get a program built with PIE, until I switched to the hardened compiler, anyway. I got tired of that, eventually, and now use the plain vanilla 4.1 compiler and standard executables. (As a programmer who likes handwritten parsers, I like the 4.1 compiler because it has a handwritten parser. :) ) -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpMKFO7Mf2sA.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
Daniel Iliev <[EMAIL PROTECTED]> skribis: > Well, then I have to simplify more (because of my lack of knowledge) and > ask what are the pros and cons to use PIC when building a program and a > share library? When a program runs it needs to know the addresses of variables, subroutines, etc. A shared library can’t know those addresses until run time, when it gets linked into the program. Therefore its code needs to have fancy things done to it so it can be taught where to find things at run time. The PIC stuff is largely overhead. A static library is linked in at program build time, and so doesn’t have this overhead. My wild guess is that prelink would need position independent executables because the build-time linker (/usr/bin/ld) doesn’t know how to link a program to a shared library as if it were a static library. -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgplhBu36sDuu.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
Simon Stelling wrote: > Simon Stelling wrote: >> Pro is your able to run it on an amd64. Con is it can drastically >> slow down code (sometimes), and just plain doesn't make sense. > > Err, this is missing a bit: > > Pro of applying it to objects used in shared libs: You can run it. > > Con of applying it to objects used in executables: It can slow down > things. > Thanks again! OK, you convinced me: As my purpose is to let portage build the fastest code possible, "-fpic" goes out of my CFLAGS -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Simon Stelling wrote: > Daniel Iliev wrote: >> Are you proposing me to put -fpie in the CFLAGS? > > Dear God, no! It's automatically appended where needed (read: hardened). > After a definitive answer like this (especially when it comes from @gentoo.org) there's nothing left for me but to erase the word "-fpie" from my vocabulary! Thanks! ;-) -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Hemmann, Volker Armin wrote: > On Wednesday 27 September 2006 07:50, Daniel Iliev wrote: > > >> 1) I use CFLAGS="-march=athlon64 -mfpmath=sse -msse -msse2 -msse3 >> -m3dnow -mmmx -O3 -fomit-frame-pointer -pipe -fpic". P >> > > -mfpmath=sse not needed. amd64 uses sse for math by default. remove that flag > -msse not needed, see above > -msse2 not needed, see above > -msse3 can be set, but only if your CPU supports it. Not all CPUs do. > Check /proc/cpuinfo for 'pni' > -m3dnow just no. sse supersedes it. Also it is a '32bit flag' > -mmmx see above > -O3 don't do it. O2 is much, much safer and not really slower. It will > prevent > a lot of breakage. > -fomit-frame-pointer not needed > -pipe a good flag > -fpic NO! Really, really really no! Don't do it! It is just wrong. Stop it > now! This flag is not needed! Even for prelink on 32bit it was never needed > (because everything that could compiled with that flag set it anyway). > Please, read the documentation and remove that flag ASAP. > > so, march=k8 -O2 -pipe > would be the result, if you remove all superflous and dangerous flags. > > > >> 2) I see too many flags that are disabled by the profile - the kind with >> the parenthesis around them, like "(-3dnow)". Why? As I mentioned above >> I enable some of these through my CFLAGS - e.g. (-mmx), (-mmxext), >> (-sse) and (-sse2) and everything works perfect. >> > > because 3dnow, mmx&co are useflags for 32bit code that was optimized for that > extensions. If you use that code in 64bit apps, certain breakage is the > result. And if something does not break, it will be A LOT slower. > > Don't use that flags. They are bad for amd64. Trust the devs, they know > better > than you or me. > Thank you very much for this reply. I'll follow your advise and remove the redundant flags. About trusting the devs - well, it depends. I trust them 100% if I need a rock stable system. In that case I would not dare to divert from any of the official instructions. BUT. Devs always tent to advertise the safest ways - this brings users no/less headaches and therefore less bug-reports ;-) My case however is slightly different - I'm talking about my home desktop which is dedicated for experiments and fun. So I'm not afraid to break the system here and rebuild it again. In this particular moment my purpose is to get the most out of the hardware no matter the stability. So I'll leave -O3 ;-) BTW, Everyone, I'm observing something very interesting: I was told not to go gentoo-amd64 for it was not stable. I was told not to migrate because there were still many important programs pending to be ported. I read almost everywhere about headaches and breakages. Reading your replies in this thread also suggests strictly following the official way otherwise - problems. It is very strange - I was ready to meet tons of major problems but I haven't met a single one yet. It is my opinion that the possibility of problems on gentoo-amd64 is highly overrated. I installed it with no problems, I obviously have tweaked it a lot beyond normal and what I see is a perfectly working system. It appears that gentoo-amd64 team along with the GNU, linux-kernel and all other nice guys who provide free/open source software have done a great work and we owe them BIG THANKS. I just wonder how come that so many people talk about some non-existing problems. How come that still in my first try I have bootstrapped from stage3, made "emerge -e system", installed xfce4, gnome, firefox, thunderbird, and a bunch of other packages along with all their dependencies, then made "emerge -e world" and after all this compiling I had to do "emerge --resume" only once when some package wanted mysql build with -fpic flag. I'm I lucky or what? ;-) -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
"Hemmann, Volker Armin" <[EMAIL PROTECTED]> skribis: > so, march=k8 -O2 -pipe > would be the result, if you remove all superflous and dangerous > flags. I endorse this setting. IMO as a programmer, other flags are for programmers. :) -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpLvdYhlyDHv.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
Simon Stelling wrote: Pro is your able to run it on an amd64. Con is it can drastically slow down code (sometimes), and just plain doesn't make sense. Err, this is missing a bit: Pro of applying it to objects used in shared libs: You can run it. Con of applying it to objects used in executables: It can slow down things. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Daniel Iliev wrote: Are you proposing me to put -fpie in the CFLAGS? Dear God, no! It's automatically appended where needed (read: hardened). -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Daniel Iliev wrote: Well, then I have to simplify more (because of my lack of knowledge) and ask what are the pros and cons to use PIC when building a program and a share library? Pro is your able to run it on an amd64. Con is it can drastically slow down code (sometimes), and just plain doesn't make sense. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Pawel Kraszewski wrote: > That's what 'pic' USE flag is for... > $ euse -i pic > global use flags (searching: pic) > > > [+ C ] pic - Build Position Independent Code. Do not utilize this flag > unless you know what you're doing. > > > "fpic breaks things". Trust Gentoo developers. They don't spread FUD. If they > say it breaks, it surely does. You just haven't been struck by it. Yet. > > > Thanks. I know about this USE flag and it is (of course) turned on here. ;-) -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Simon Stelling wrote: > Daniel Iliev wrote: >> So, both flags let gcc produce PIC for libs and programs and none of >> them lets gcc produce PIC for libs only? The next flag described in the >> man page is -fpie, which makes PIC for programs only. Something is wrong >> and don't know how to find the right explanation. > > The problem is that -fPIC is a code-generating flag, i.e. it applies > to the .o object files built. The compiler can't work out whether that > object is used in a program or a shared library, so it can't know > whether using PIC is a good idea or not. > Well, then I have to simplify more (because of my lack of knowledge) and ask what are the pros and cons to use PIC when building a program and a share library? -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
[EMAIL PROTECTED] wrote: > Daniel Iliev <[EMAIL PROTECTED]> skribis: > >> Unfortunately I am not a C programmer and I can't be sure about how >> exactly PIC and prelink work. >> As far as I understood the mechanism (please, correct me if I'm wrong) >> prelink scans the executables to find which libs they load. Then it >> makes cache and when a program is started it uses already pre-loaded >> libs. So the program is ready for action faster. >> > > What you are interested in, probably, is PIE: position-independent > executables. These look like shared libraries but are runnable > programs. These are easy to get using the version 3.4.x compiler and > ‘hardenednossp’ specs. I suspect you will have more fun and fewer > headaches by using the 4.1.x compiler and no prelink. There are > already enough extra headaches in amd64 Gentoo, compared to x86 > Gentoo! :) > > Yep! gcc -v says: Target: x86_64-pc-linux-gnu.gcc version 4.1.1 (Gentoo 4.1.1) Are you proposing me to put -fpie in the CFLAGS? -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Daniel Iliev <[EMAIL PROTECTED]> skribis: > Unfortunately I am not a C programmer and I can't be sure about how > exactly PIC and prelink work. > As far as I understood the mechanism (please, correct me if I'm wrong) > prelink scans the executables to find which libs they load. Then it > makes cache and when a program is started it uses already pre-loaded > libs. So the program is ready for action faster. What you are interested in, probably, is PIE: position-independent executables. These look like shared libraries but are runnable programs. These are easy to get using the version 3.4.x compiler and ‘hardenednossp’ specs. I suspect you will have more fun and fewer headaches by using the 4.1.x compiler and no prelink. There are already enough extra headaches in amd64 Gentoo, compared to x86 Gentoo! :) -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpXQRNjbCbET.pgp Description: PGP signature
Re: [gentoo-amd64] First Impressions
On Wednesday 27 September 2006 07:50, Daniel Iliev wrote: > > 1) I use CFLAGS="-march=athlon64 -mfpmath=sse -msse -msse2 -msse3 > -m3dnow -mmmx -O3 -fomit-frame-pointer -pipe -fpic". P -mfpmath=sse not needed. amd64 uses sse for math by default. remove that flag -msse not needed, see above -msse2 not needed, see above -msse3 can be set, but only if your CPU supports it. Not all CPUs do. Check /proc/cpuinfo for 'pni' -m3dnow just no. sse supersedes it. Also it is a '32bit flag' -mmmx see above -O3 don't do it. O2 is much, much safer and not really slower. It will prevent a lot of breakage. -fomit-frame-pointer not needed -pipe a good flag -fpic NO! Really, really really no! Don't do it! It is just wrong. Stop it now! This flag is not needed! Even for prelink on 32bit it was never needed (because everything that could compiled with that flag set it anyway). Please, read the documentation and remove that flag ASAP. so, march=k8 -O2 -pipe would be the result, if you remove all superflous and dangerous flags. > > 2) I see too many flags that are disabled by the profile - the kind with > the parenthesis around them, like "(-3dnow)". Why? As I mentioned above > I enable some of these through my CFLAGS - e.g. (-mmx), (-mmxext), > (-sse) and (-sse2) and everything works perfect. because 3dnow, mmx&co are useflags for 32bit code that was optimized for that extensions. If you use that code in 64bit apps, certain breakage is the result. And if something does not break, it will be A LOT slower. Don't use that flags. They are bad for amd64. Trust the devs, they know better than you or me. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Daniel Iliev wrote: So, both flags let gcc produce PIC for libs and programs and none of them lets gcc produce PIC for libs only? The next flag described in the man page is -fpie, which makes PIC for programs only. Something is wrong and don't know how to find the right explanation. The problem is that -fPIC is a code-generating flag, i.e. it applies to the .o object files built. The compiler can't work out whether that object is used in a program or a shared library, so it can't know whether using PIC is a good idea or not. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Dnia środa, 27 września 2006 07:50, Daniel Iliev napisał: > 1) I use CFLAGS="-march=athlon64 -mfpmath=sse -msse -msse2 -msse3 > -m3dnow -mmmx -O3 -fomit-frame-pointer -pipe -fpic". Portage complains > with *red letters* about the fpic flag. Every time I emerge something it > says that "fpic breaks things", but I haven't met a single breakage so > far. Is that a bug? Actually there was an ebuild which could not be > compiled if mysql was compiled w/o "fpic". I'm not 100% sure but AFAIR > it was dev-perl/DBD-mysql. That's what 'pic' USE flag is for... $ euse -i pic global use flags (searching: pic) [+ C ] pic - Build Position Independent Code. Do not utilize this flag unless you know what you're doing. "fpic breaks things". Trust Gentoo developers. They don't spread FUD. If they say it breaks, it surely does. You just haven't been struck by it. Yet. -- Pawel Kraszewski www.kraszewscy.net -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
Christoph Mende wrote: > One thing that I think wasn't mentioned yet, while -fPIC is needed for > libraries, it must be disabled for binaries (don't know if that's true > for prelink), as portage says, it might break things and your binaries > are most likely becoming slower when you compile them with -fPIC. > Unfortunately I am not a C programmer and I can't be sure about how exactly PIC and prelink work. As far as I understood the mechanism (please, correct me if I'm wrong) prelink scans the executables to find which libs they load. Then it makes cache and when a program is started it uses already pre-loaded libs. So the program is ready for action faster. My only way to judge about the result is to test. Taking this in mind you can understand that the part about "becoming slower" sounds very disturbing to me. ;-) Can you, please, explain how it comes that PIC is good for libs and bad for execs? I'm confused because the gcc man page says: -fpic Generate position-independent code (PIC) --snip-- If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. -snip- *The 386 has no such limit* -fPIC If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. *This option makes a difference on the m68k, PowerPC and SPARC.* So, both flags let gcc produce PIC for libs and programs and none of them lets gcc produce PIC for libs only? The next flag described in the man page is -fpie, which makes PIC for programs only. Something is wrong and don't know how to find the right explanation. -- Best regards, Daniel -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] [OT] Filesharing client
Relatively stupid question, but since I can no longer compile gtk-gnutella on my box here (and I haven't had time to look at the problem just yet), is there another good P2P client that runs on amd64? I'd like to have access to fasttrack and gnutella networks if possible. I am not much for spending a ton of time configuring, but I will if i need to. Ideas? -- Ceterum censeo, Carthago delenda est. Mark Haney Sr. Systems Administrator ERC Broadband (828) 350-2415 -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: emerge sandbox is using the wrong host id
On Wednesday 27 September 2006 14:01, Peter Humphrey wrote: > Unfortunately, module-init-tools doesn't compile - it fails on "too many > filenames given". I've opened a bug report. ... which turned out to be a duplicate of 149210. I've fixed my box thus pro tem: # cat /etc/portage/env/sys-apps/module-init-tools CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants" CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants"CHOST="x86_64-pc-linux-gnu" If my global flags change in /etc/make.conf, I shall probably forget to make corresponding changes to anything under /etc/portage/env. This could be avoided if those files could be used to specify flags to be deleted from the environment. Perhaps I should put in a feature request. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: emerge sandbox is using the wrong host id
On Wednesday 27 September 2006 13:49, Duncan wrote: > Very glad you finally got it fixed! =8^) Thanks for the fix report. Unfortunately, module-init-tools doesn't compile - it fails on "too many filenames given". I've opened a bug report. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: How To Play WMV?
"Joaquim Quinteiro Uchoa" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 27 Sep 2006 09:29:25 -0300: > Good news about suport in ffmpeg. But it doesn't work in 0.4.9_p20060530. And > the version 0.4.9_p20060816 is masked: > > [I] media-video/ffmpeg > Available versions: 0.4.9_p20050226-r3 0.4.9_p20051216 > 0.4.9_p20060302 *0.4.9_p20060517 0.4.9_p20060530 [M ]0.4.9_p20060816 > > So, needs to put a entry in /etc/portage/package.unmask to use this version. FWIW, xine seems to be playing some wmv here, not others. I know divx plays and suspect the *.wmv files that play are actually divx codec. That's 64-bit xinelib, no mplayer (since xinelib has always "just worked" in far more cases than mplayer, here), and no proprietaryware codecs such as win32codecs. ffmpeg is the 20060530 edition. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: emerge sandbox is using the wrong host id
Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 27 Sep 2006 12:21:46 +: > I found the answer. The problem has been caused by the broken > eselect-compiler. Even after it's purged from the system, it leaves debris > in /usr/bin. I followed the discussion of bug 133209, which showed me how > to clear up the mess. > > Emerge -e system is now running on a clean system, and has compiled sandbox > just fine. Very glad you finally got it fixed! =8^) Thanks for the fix report. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] How To Play WMV?
My 10 cents. Good news about suport in ffmpeg. But it doesn't work in 0.4.9_p20060530. And the version 0.4.9_p20060816 is masked: [I] media-video/ffmpeg Available versions: 0.4.9_p20050226-r3 0.4.9_p20051216 0.4.9_p20060302 *0.4.9_p20060517 0.4.9_p20060530 [M ]0.4.9_p20060816 So, needs to put a entry in /etc/portage/package.unmask to use this version. 2006/9/27, Christoph Mende <[EMAIL PROTECTED]>: Latest stable version of ffmpeg is supposed to support wmv (at least ffmpeg-0.4.9_p20060816 has working wmv for me here), which is imho a better solution. 2006/9/27, Daniel Iliev <[EMAIL PROTECTED]>: > Hello, > > My google digging wasn't helpful this time. Perhaps I can't find the > right search keywords. ;-( > On a 32bit gentoo system appropriate codec comes with > "media-libs/win32codecs" and such movies can be played by mplayer. On > amd64 mplayer can't be emerged with "USE=win32codecs", because the flag > is disabled by the profile. > > Please, advise me how to set up an amd64 based system to play clips of > "*.wmv" format or send me a link to some information on this subject. > > Thanks in advance! > > > -- > gentoo-amd64@gentoo.org mailing list > > -- gentoo-amd64@gentoo.org mailing list -- []s Joaquim -- (o_Joaquim Quinteiro Uchoa //\Consultor Linux e EaD U_/_Linux User # 100534 -- -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: emerge sandbox is using the wrong host id
On Tuesday 26 September 2006 12:20, Duncan wrote: > ... I wonder how much of your earlier problems might have the same > thing? Oh, well, hindsight's always 20/20, as they say. One more thing > to add to our list of things to check... I found the answer. The problem has been caused by the broken eselect-compiler. Even after it's purged from the system, it leaves debris in /usr/bin. I followed the discussion of bug 133209, which showed me how to clear up the mess. Emerge -e system is now running on a clean system, and has compiled sandbox just fine. Thanks for the help, all. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] processor @ 100% when compilig...
TY, was a little worried... - Original Message - From: Fabrice Toppi To: gentoo-amd64@lists.gentoo.org Sent: Wednesday, September 27, 2006 1:30 PM Subject: Re: [gentoo-amd64] processor @ 100% when compilig... Hi,Yes it's normal, you'd rather have cpu @ 5% and spend 10hours to compile something ?The swap is used when you're out of RAM. It's normal too. 2006/9/27, Patric Douhane < [EMAIL PROTECTED]>: Hi, watched the system when it compiled, processor @ 99-100%, RAM ~20%, is this normal? Also what is the swap mem for, it used only about 200K, out of 500M. AMD64 3400+ -march=K8
Re: [gentoo-amd64] processor @ 100% when compilig...
Patric Douhane <[EMAIL PROTECTED]> skribis: > Hi, watched the system when it compiled, processor @ 99-100%, RAM > ~20%, is this normal? Also what is the swap mem for, it used only > about 200K, out of 500M. Your processor is eager to do work! :) Swap is ‘emergency memory’ if you run out of RAM. Linux kernels don’t use swap much, and some programs that might need swap space, such as GIMP, prefer to maintain their own swap files (I guess so they don’t use up RAM that other programs could use). It’s good if your aren’t using much swap. Having some swap space is something I do mainly because I am obsessive-compulsive (literally). :) -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpPwY0Z2i32y.pgp Description: PGP signature
Re: [gentoo-amd64] Re: First Impressions
Duncan <[EMAIL PROTECTED]> skribis: > > When I really want a program to start quickly, though, I use the > > sticky bit, so the program stays in memory. I think this is the > > default for GNU Emacs. > > Eh? That's a rather dated use of that bit, AFAIK. Thus it gets very little use. :) In my experience programs that start up slowly often have bugs causing it. For example, Opera slows down dramatically if you have a lot of fonts, which I do; because of this, I run Opera under a separate fontconfig. Programs that use Pango, such as Inkscape, can be slow to start up if you have a lot of fonts, though they won’t slow down, once started, as dramatically as does Opera. GIMP has its own code for listing your fonts and starts up quickly. -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpJZOammzLcC.pgp Description: PGP signature
Re: [gentoo-amd64] processor @ 100% when compilig...
Hi,Yes it's normal, you'd rather have cpu @ 5% and spend 10hours to compile something ?The swap is used when you're out of RAM. It's normal too.2006/9/27, Patric Douhane < [EMAIL PROTECTED]>: Hi, watched the system when it compiled, processor @ 99-100%, RAM ~20%, is this normal? Also what is the swap mem for, it used only about 200K, out of 500M. AMD64 3400+ -march=K8
Re: [gentoo-amd64] How To Play WMV?
Latest stable version of ffmpeg is supposed to support wmv (at least ffmpeg-0.4.9_p20060816 has working wmv for me here), which is imho a better solution. 2006/9/27, Daniel Iliev <[EMAIL PROTECTED]>: Hello, My google digging wasn't helpful this time. Perhaps I can't find the right search keywords. ;-( On a 32bit gentoo system appropriate codec comes with "media-libs/win32codecs" and such movies can be played by mplayer. On amd64 mplayer can't be emerged with "USE=win32codecs", because the flag is disabled by the profile. Please, advise me how to set up an amd64 based system to play clips of "*.wmv" format or send me a link to some information on this subject. Thanks in advance! -- gentoo-amd64@gentoo.org mailing list -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
One thing that I think wasn't mentioned yet, while -fPIC is needed for libraries, it must be disabled for binaries (don't know if that's true for prelink), as portage says, it might break things and your binaries are most likely becoming slower when you compile them with -fPIC. 2006/9/27, Daniel Iliev <[EMAIL PROTECTED]>: Hello, everyone! It's my first mail to this list. I hope the community here is as friendly as the one at the general "gentoo-user" list ;-) Please, forgive me if open some threads about already discussed issues until I catch up with rhythm of the list. So let me start a with 2 newbie questions caused by my first impressions from the x86_64 world: 1) I use CFLAGS="-march=athlon64 -mfpmath=sse -msse -msse2 -msse3 -m3dnow -mmmx -O3 -fomit-frame-pointer -pipe -fpic". Portage complains with *red letters* about the fpic flag. Every time I emerge something it says that "fpic breaks things", but I haven't met a single breakage so far. Is that a bug? Actually there was an ebuild which could not be compiled if mysql was compiled w/o "fpic". I'm not 100% sure but AFAIR it was dev-perl/DBD-mysql. 2) I see too many flags that are disabled by the profile - the kind with the parenthesis around them, like "(-3dnow)". Why? As I mentioned above I enable some of these through my CFLAGS - e.g. (-mmx), (-mmxext), (-sse) and (-sse2) and everything works perfect. -- gentoo-amd64@gentoo.org mailing list -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: First Impressions
[EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 27 Sep 2006 05:46:29 -0500: > Alright. Another reason would be to use PaX for security. I’ve used > PaX and what I did for that, to get PIC code, was to use the > ‘hardened’ 3.x compiler. The ‘hardened no SSP’ setting would be the > one for prelink, I think. Right on the security thing in general, tho I'm not sure of the specific specs files specifics. (Wow, that sounds weird! ) > When I really want a program to start quickly, though, I use the > sticky bit, so the program stays in memory. I think this is the > default for GNU Emacs. Eh? That's a rather dated use of that bit, AFAIK. See the wikipedia (stub entry) here: http://en.wikipedia.org/wiki/Sticky_bit While keeping a program in memory was the original use of that bit, it hasn't been used for that for a long time, as modern swapping and caching methods tend to be decently efficient at that on their own. In modern system use, the sticky bit has significance only for directories, where it affects deletion/rename permissions in multiple user access situations, such as the /tmp dir, which is commonly world writable but set sticky so only a file's owner or root can delete files. Of course, you can use the sticky bit on non-dirs for other things if you wish, but there's no system significance on executables as there once was. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] processor @ 100% when compilig...
Hi, watched the system when it compiled, processor @ 99-100%, RAM ~20%, is this normal? Also what is the swap mem for, it used only about 200K, out of 500M. AMD64 3400+ -march=K8
Re: [gentoo-amd64] First Impressions
Daniel Iliev <[EMAIL PROTECTED]> skribis: > [EMAIL PROTECTED] wrote: > > > I guess the best question might be ‘Why do you want -fpic?’ > > > > > I use prelink [1] which requires PIC in order to work. At least that is > true for X86. That is the only reason - I suppose if it works on x86_64 > it would have the same requirements. Alright. Another reason would be to use PaX for security. I’ve used PaX and what I did for that, to get PIC code, was to use the ‘hardened’ 3.x compiler. The ‘hardened no SSP’ setting would be the one for prelink, I think. When I really want a program to start quickly, though, I use the sticky bit, so the program stays in memory. I think this is the default for GNU Emacs. -- Barry.SCHWARTZ at chemoelectric.org http://chemoelectric.org Free stuff / Senpagaj varoj: http://crudfactory.com (PDF) 'Democracies don't war; democracies are peaceful countries.' - Bush (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html) pgpSBsXLXvdTz.pgp Description: PGP signature
Re: [gentoo-amd64] How To Play WMV?
Thank you, guys! -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: First Impressions
Duncan wrote: > Daniel Iliev <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Wed, 27 Sep 2006 08:50:03 +0300: > > >> So let me start a with 2 newbie questions caused by my first impressions >> from the x86_64 world: >> >> 1) I use CFLAGS="-march=athlon64 -mfpmath=sse -msse -msse2 -msse3 >> -m3dnow -mmmx -O3 -fomit-frame-pointer -pipe -fpic". Portage complains >> with *red letters* about the fpic flag. Every time I emerge something it >> says that "fpic breaks things", but I haven't met a single breakage so >> far. Is that a bug? Actually there was an ebuild which could not be >> compiled if mysql was compiled w/o "fpic". I'm not 100% sure but AFAIR >> it was dev-perl/DBD-mysql. >> >> 2) I see too many flags that are disabled by the profile - the kind with >> the parenthesis around them, like "(-3dnow)". Why? As I mentioned above >> I enable some of these through my CFLAGS - e.g. (-mmx), (-mmxext), >> (-sse) and (-sse2) and everything works perfect. >> > > It seems that you missed some of the Gentoo/AMD64 documentation. > Many/most of your questions are answered there. Unfortunately, I'm not > aware of a simple easy to use list of everything in one spot, so it's > reading a bit of documentation here, a bit more there, etc. > > The main Gentoo/AMD64 project page. (This would be the logical place for > such a list, but it's more the project page, tho it links some of the > docs, it's just not as easy to find those links as it could be.) > http://amd64.gentoo.org > > Gentoo/AMD64 FAQ: > http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml > > Gentoo/AMD64 HOWTOs. (There's one on -fPIC here, tho the explanation is > a bit developer-centric.) > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml > > A brief direct answer to your questions follows: > > * The sse etc CFLAGS are arch dependent. Unlike x86 where the > mmx/sse/other-extensions instructions were added as the arch matured, on > amd64, they are part of the definition of the arch itself. All x86_64 > (amd64) CPUs will have mmx/sse/sse2, etc. Thus, -march=athlon64 already > tells gcc these are available to use where it wants/needs to. The others > don't therefore provide gcc any more information than what it already has. > > * -fomit-frame-pointer isn't needed on 64-bit amd64 either, as it's turned > on for all -O levels on archs (including amd64) where doing so doesn't > interfere with debugging. (See the gcc manpage, under -O optimization.) > You may wish to continue to specify it for stuff that's compiled for > 32-bit, however, including parts of gcc, a version of glibc, a version of > the (portage) sandbox library, etc. > > * Generally speaking, -fPIC is required on amd64 for ALL LIBRARIES but the > ebuilds normally take care of it. Under certain circumstances (like > unsupported CFLAGS), the configure scripts will turn it off by mistake, see > the above mentioned -fPIC HOWTO link for details, but the solution isn't > to add it to your CFLAGS, as that means it will be used for executable > applications as well as libraries, and /some/ applications /do/ break with > it. Not many, but some, and if it's in your CFLAGS, you WILL have bugs > you file closed as INVALID or the like, due to CFLAG abuse. If there's > something not working without it, then THAT'S a bug and should be filed as > such (unless it's due to use of CFLAGS gcc doesn't support and warns > about, thus triggering the configure script detection problem discussed > above and in the HOWTO). > > * The profile "disabled" USE flags are simply hard-locked either on or > off by the profile, so aren't a USE flag option. It does NOT mean whatever > the USE flag controls is actually disabled. Sometimes, as with the > multilib USE flag, it can mean it's /enabled/. It just means that the > profile is set up to control it, generally for a pretty good reason. In > the particular cases you mention, the way Gentoo uses the SSE and similar > USE flags is 32-bit specific, enabling 32-bit specific assembler code in > the ebuild, for instance. As already mentioned, the AMD64 arch by > definition already has these features activated, so no 64-bit USE flags > are necessary, and enabling the 32-bit USE flags will cause breakage since > it activates 32-bit specific code in many instances. Thus the amd64 > profiles have a /very/ good reason to hard-lock these USE flags "off". An > example where a USE flag is hard-locked ON by a profile would be multilib. > The normal AMD64 profiles are all multilib and thus lock this flag ON (tho > it's still shown as disabled), while 64-bit-only profiles lock it OFF. > > A couple of other notes: > > Portage now supports per-package CFLAGS and certain other variables as > controlled by the environment (as long as they are used in an ebuild.sh > phase, not the python phase, since execution is via a bashrc hook). > Create /etc/portage/env/ as a directory, populated with package > or package-version files. The contents of these f
Re: [gentoo-amd64] First Impressions
Dice R. Random wrote:
>
> It is not necessary to tell gcc to use special instruction sets for
> your processor. When you specify -march gcc automatically knows
> exactly what instructions your processor is capable of utilizing most
> effectively.
I'm not sure about this. Tonight I'll make a test: I'll compile a
package with and without these flags and watch the output and the outcome.
>
> I am not familiar with PIC, but if portage gives a big red warning
> about explicitly enabling it in your CFLAGS I'm sure that there have
> been problems with it. If a package requires the flag then it should
> enable it in its own local CFLAGS.
>
Already answered about Position Independent Code and why I use it.
Shortly: http://www.gentoo.org/doc/en/prelink-howto.xml
> A 3dnow instruction path isn't always the best optimization for every
> user and every package. Also, AMD's Athlon and Opteron processors are
> not the only ones supported under the amd64 arch, there are also
> Intel's x86-64 processors to consider. While I imagine that Intel
> processors can execute 3dnow instructions I also imagine that SSE
> would be faster.
I'm really not sure here. I cant tell which is better -3dnow(ext) or
sse{1..3}, but isn't it best if one enables all kinds of optimizations
supported by the CPU?
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] First Impressions
[EMAIL PROTECTED] wrote: > I guess the best question might be ‘Why do you want -fpic?’ > I use prelink [1] which requires PIC in order to work. At least that is true for X86. That is the only reason - I suppose if it works on x86_64 it would have the same requirements. [1] http://www.gentoo.org/doc/en/prelink-howto.xml -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: First Impressions
Daniel Iliev <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 27 Sep 2006 08:50:03 +0300: > So let me start a with 2 newbie questions caused by my first impressions > from the x86_64 world: > > 1) I use CFLAGS="-march=athlon64 -mfpmath=sse -msse -msse2 -msse3 > -m3dnow -mmmx -O3 -fomit-frame-pointer -pipe -fpic". Portage complains > with *red letters* about the fpic flag. Every time I emerge something it > says that "fpic breaks things", but I haven't met a single breakage so > far. Is that a bug? Actually there was an ebuild which could not be > compiled if mysql was compiled w/o "fpic". I'm not 100% sure but AFAIR > it was dev-perl/DBD-mysql. > > 2) I see too many flags that are disabled by the profile - the kind with > the parenthesis around them, like "(-3dnow)". Why? As I mentioned above > I enable some of these through my CFLAGS - e.g. (-mmx), (-mmxext), > (-sse) and (-sse2) and everything works perfect. It seems that you missed some of the Gentoo/AMD64 documentation. Many/most of your questions are answered there. Unfortunately, I'm not aware of a simple easy to use list of everything in one spot, so it's reading a bit of documentation here, a bit more there, etc. The main Gentoo/AMD64 project page. (This would be the logical place for such a list, but it's more the project page, tho it links some of the docs, it's just not as easy to find those links as it could be.) http://amd64.gentoo.org Gentoo/AMD64 FAQ: http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml Gentoo/AMD64 HOWTOs. (There's one on -fPIC here, tho the explanation is a bit developer-centric.) http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml A brief direct answer to your questions follows: * The sse etc CFLAGS are arch dependent. Unlike x86 where the mmx/sse/other-extensions instructions were added as the arch matured, on amd64, they are part of the definition of the arch itself. All x86_64 (amd64) CPUs will have mmx/sse/sse2, etc. Thus, -march=athlon64 already tells gcc these are available to use where it wants/needs to. The others don't therefore provide gcc any more information than what it already has. * -fomit-frame-pointer isn't needed on 64-bit amd64 either, as it's turned on for all -O levels on archs (including amd64) where doing so doesn't interfere with debugging. (See the gcc manpage, under -O optimization.) You may wish to continue to specify it for stuff that's compiled for 32-bit, however, including parts of gcc, a version of glibc, a version of the (portage) sandbox library, etc. * Generally speaking, -fPIC is required on amd64 for ALL LIBRARIES but the ebuilds normally take care of it. Under certain circumstances (like unsupported CFLAGS), the configure scripts will turn it off by mistake, see the above mentioned -fPIC HOWTO link for details, but the solution isn't to add it to your CFLAGS, as that means it will be used for executable applications as well as libraries, and /some/ applications /do/ break with it. Not many, but some, and if it's in your CFLAGS, you WILL have bugs you file closed as INVALID or the like, due to CFLAG abuse. If there's something not working without it, then THAT'S a bug and should be filed as such (unless it's due to use of CFLAGS gcc doesn't support and warns about, thus triggering the configure script detection problem discussed above and in the HOWTO). * The profile "disabled" USE flags are simply hard-locked either on or off by the profile, so aren't a USE flag option. It does NOT mean whatever the USE flag controls is actually disabled. Sometimes, as with the multilib USE flag, it can mean it's /enabled/. It just means that the profile is set up to control it, generally for a pretty good reason. In the particular cases you mention, the way Gentoo uses the SSE and similar USE flags is 32-bit specific, enabling 32-bit specific assembler code in the ebuild, for instance. As already mentioned, the AMD64 arch by definition already has these features activated, so no 64-bit USE flags are necessary, and enabling the 32-bit USE flags will cause breakage since it activates 32-bit specific code in many instances. Thus the amd64 profiles have a /very/ good reason to hard-lock these USE flags "off". An example where a USE flag is hard-locked ON by a profile would be multilib. The normal AMD64 profiles are all multilib and thus lock this flag ON (tho it's still shown as disabled), while 64-bit-only profiles lock it OFF. A couple of other notes: Portage now supports per-package CFLAGS and certain other variables as controlled by the environment (as long as they are used in an ebuild.sh phase, not the python phase, since execution is via a bashrc hook). Create /etc/portage/env/ as a directory, populated with package or package-version files. The contents of these files will be sourced into the ebuild.sh execution environment for every phase that uses ebuild.sh. CFLAGS and similar variables as found in these files REPLACE (that is, the
