|
|
|
October 21st, 2009
09:17 pm - Machinarium on 64bit Gentoo Linux
I had to spend a few hours trying to get Machinarium(flash required) running on my laptop the other night. Turns out the solution was too easy:
# USE=32bit emerge -av www-plugins/adobe-flash
Damn.
PS. if you like old-school adventure games, puzzles, or desolate post-apocalyptic cityscapes populated by melancholy anthropomorphized robots (yay), you could do worse than support Linux gaming by dropping 20 bucks on this fine piece of work.
|
October 18th, 2009
09:09 pm - broken libgomp.la in recent GCC upgrades (aka "my imagemagick's broken")
Yeah, this bug is back again. Turns out the code that fixes the paths in gcc's own .la files was broken on new version installs. This means that everyone in stable that updated to gcc-4.3.4 and anyone in unstable that updated to 4.4.2 in the last week or so should resync their portage tree and rebuild gcc now.
See https://bugs.gentoo.org/283761 for the poop.
We won't be doing a revbump because this wasn't version specific. It just sucks that no one noticed the problem until a new version was released.
edit: if you're still getting errors when building, such as
/bin/grep: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
/bin/sed: can't read /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
libtool: link: `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la' is not a valid libtool archive
where "4.4.1" is the previous version of gcc you upgraded from, run
# fix_libtool_files.sh <old gcc version>
|
July 31st, 2009
02:11 am - why you should keep multiple gcc versions around (a case study in stupidity)
So i bumped dev-libs/cloog-ppl to a newer version just now. cloog-ppl (and it's buddy PPL) are new dependencies of the new Graphite framework in GCC 4.4 (still masked). They're optional dependencies, and on a whim I wanted to see if configure would fail if they were missing or just detect it and continue on. So I did this:
emerge -C cloog-ppl
Oops.
configure: error: C compiler cannot create executables
Every Gentoo user has seen this at some point. It's a very general error that can range in meaning from "you mispelled a CFLAG" to "wow you're screwed". I knew what the error here would be without looking, but for those following along at home:
/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.4.1/cc1: error while loading shared libraries:
libcloog.so.0: cannot open shared object file: No such file or directory
(usually you would find this in the config.log of the package being compiled)
Ok, so I just hosed the compiler. Dumb mistake. Now, here's how we fix it.
halo ~ # gcc-config -l
[1] x86_64-unknown-linux-gnu-4.3.3
[2] x86_64-unknown-linux-gnu-4.4.1 *
[3] x86_64-unknown-linux-gnu-4.4.2-pre9999
[4] x86_64-unknown-linux-gnu-4.5.0-pre9999
Usually I would have three or four more versions here (3.4, 4.0, 4.1, 4.2) but this is a relatively new install. As luck would have it though, I have exactly one version that will work here. 4.3.3 doesn't have graphite support and therefore won't be linked against libcloog.
So, gcc-config 1, etc. emerge -av1 cloog-ppl.
libtool: link: x86_64-unknown-linux-gnu-gcc -Wall -fomit-frame-pointer -O2 -g -march=core2
-msse4.1 -fomit-frame-pointer -pipe -Wl,--hash-style=gnu -o .libs/cloog cloog.o -Wl,--as-needed
./.libs/libcloog.so -L/usr/lib64 /usr/lib64/libppl_c.so /usr/lib64/libppl.so /usr/lib64
/libgmpxx.so /usr/lib64/libgmp.so
/usr/lib64/libppl_c.so: undefined reference to `std::ctype::_M_widen_init() const@GLIBCXX_3.4.11'
Or not. Yay, symbol versioning. Another thing every Gentoo user has run into when switching GCC versions. To make a long story short, libppl_c.so (PPL) is looking for a versioned symbol in libstdc++.so.6 from GCC 4.4. When we switched to GCC 4.3, that symbol version (here GLIBCXX_3.4.11) no longer exists. Solution? Rebuild PPL. But, this results in a similar error:
libtool: link: x86_64-unknown-linux-gnu-g++ -frounding-math -O2 -g -march=core2 -msse4.1 -fomit-
frame-pointer -pipe -W -Wall -Wl,--as-needed -Wl,--hash-style=gnu -o .libs/ppl-config BUGS.o
COPYING.o CREDITS.o ppl-config.o ./.libs/libppl.so -L/usr/lib64 /usr/lib64/libgmpxx.so
/usr/lib64/libgmp.so
/usr/lib64/libgmpxx.so: undefined reference to `std::ctype::_M_widen_init() const@GLIBCXX_3.4.11'
As you can see, downgrading GCC versions with gcc-config breaks the linking of a lot of C++ libraries. (this is why I hate testing unstable GCC versions on KDE).
So just keep going down the line, attempting to rebuild whatever breaks next, until you actually manage to fix something. If you don't know what package a library belongs to, use one of the many utilities that may be installed on your system, like `equery b` or `qfile`, that maps a filename to package. In this particular case, dev-libs/gmp was the last package needing to be rebuilt. Next, go back up the chain - rebuild ppl, and finally cloog-ppl should build successfully. Switch back to your original GCC version, do a little dance, and go about your day.
|
May 31st, 2009
07:21 pm - analyze-x86
Ward Poelmans has sent me an update to the analyze-x86 script which has been floating around forever to add support for SSE4.1, SSE4.2, and SSE4a instruction sets.
dirtyepic@halo ~ $ ./analyze-x86 /usr/lib64/libx264.so
Checking vendor_id string... GenuineIntel
Disassembling /usr/lib64/libx264.so, please wait...
i486: 229 i586: 1 ppro: 415 mmx: 13319 sse: 3362 sse2: 4012 sse3: 292 sse4.1: 32 sse4.2: 0
This binary was found to contain the cpuid instruction.
It may be able to conditionally execute instructions if
they are supported on the host (i586+).
/usr/lib64/libx264.so will run on Intel Core 2 Duo (Penryn) w/ SSE4.1 or higher processor.
You can grab it from http://dev.gentoo.org/~dirtyepic/bin/analyze-x86
|
April 27th, 2009
04:31 pm - Bored?
Are you tired of laying around the apartment, wishing you had something fun and productive to do?
NOW YOU DO!
We have 400* open bugs assigned or CC'd to maintainer-needed in bugzilla. Many of these are easy fixes, like packages not respecting CFLAGS, or CC hardcoded, or missing dependencies. You (yes, you) can earn the admiration and respect of your peers** simply by fixing _one_ maintainer-needed bug per day. How much easier could it be? And, in a limited time offer, if you go as far as to find a maintainer or herd for a maintainer-needed package, you'll receive a miniature Larry the Gender-Confused Cow bobblehead absolutely free of charge***.
Act now, repoman is standing by.
* okay, 399.
** okay, just me.
*** okay, not really
|
April 16th, 2009
11:43 am - updates
i wrote my route survey final today, the last one. this semester was a lot rougher than the last one and i really had to work at it. after missing a week early in the year due to the worst flu i've had in ten years, and then my grandma dying a month or so later, i was perpetually a class or two behind. and when i'm stressed i don't sleep, so that meant missing more classes. in the end i think i did alright though. i think i passed at least, but my high eighties average is going to take a big hit. oh well, two more weeks of field camp and then i'm back to work in Yorkton.
gentoo-wise, due largely to the efforts of loki_val, darkside, and fauli, we got GCC 4.3 stable on the major archs. i've been running 4.4 on my laptop for a few months now and things are moving nicely. the gcc-porting overlay is filling out thanks to Daniel J, who keeps throwing patches at me.
i stopped reading g-dev around March-ish. i poke my nose in every once in a while but for the most part i just ignore it. it was just getting me frustrated and then i'd end up yelling at someone and feeling bad. i really have nothing to contribute besides arguments and bikeshedding so i figured i'd just leave it to the experts.
one thing i do want to work on now is getting maintainer-needed cleaned up. we have 750 orphaned packages in the tree, many of which look like they can be herded. once that's done i want to go through the remainders and kick anything redundant, broken, unmaintained, or old. it's amazing how much crap we have that hasn't been touched in years. flameeyes' tinderbox runs have turned up a bunch of broken junk that i've never even heard of before.
of course, the problem is knowing what to kick and what to keep. gentoo-stats would be awesome here, if it existed, to tell if anyone is actually using this stuff. right now the best we can do is mask it and wait til someone complains, which is painful for everyone involved. i guess we can wait another 3 years until someone implements it or we can buckle down and bear it.
other than that, business as usual. i still wish people would fix their damned testsuites, but i'm not holding my breath. i'm really looking forward to the git migration, not because i like git but because i really really hate CVS. EAPI 3 has some promising stuff in it, as long as it doesn't get debated into mediocrity by the gentoo development process(tm). etc etc..
|
February 1st, 2009
12:08 pm - gcc-4.3.3 and broken libtool archives
There were some improvements made recently to the libtool archive (.la) handling in toolchain.eclass recently for longtime favourite bug #125728. Unfortunately, a typo slipped in that resulted in broken .la files getting installed when upgrading GCC. This happened at the same time that 4.3.3 was added to the tree, so a potentially large number of people may hit this.
This only affects packages linking against libgomp or libsupc++. The error looks like this:
-8<---
/bin/sh ./libtool --silent --tag=CC --mode=link x86_64-pc-linux-gnu-gcc
-std=gnu99 -fopenmp -march=core2 -O2 -pipe -Wall -W -pthread -no-undefined
-dlpreopen ltdl/dlopen.la -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-lfreetype -lz -o ltdl/libltdlc.la ltdl/loaders/ltdl_libltdlc_la-preopen.lo
ltdl/ltdl_libltdlc_la-lt__alloc.lo ltdl/ltdl_libltdlc_la-lt_dlloader.lo
ltdl/ltdl_libltdlc_la-lt_error.lo ltdl/ltdl_libltdlc_la-ltdl.lo
ltdl/ltdl_libltdlc_la-slist.lo ltdl/lt__strl.lo
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/libgomp.la: line 41:
libdir/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3: No such file or directory
libtool: link: warning: library
`/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/libgomp.la' was moved.
/usr/bin/nm: '/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/.libs/libgomp.a': No such
file
x86_64-pc-linux-gnu-gcc:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/.libs/libgomp.a: No such file or
directory
make[1]: *** [magick/libMagickCore.la] Error 1
--->8-
If you run into this error, simply rebuild gcc. While 4.3.3 is the most common version to be affected due to the timing of the version bump, any gcc version built on Jan 28 may be affected.
Any currently open bugs concerning this problem can be marked duplicates of bug #256636
|
January 31st, 2009
07:03 pm - Graphite
I've added support for the Graphite loop optimization framework that will be released in GCC 4.4 to my svn ebuild. Graphite requires two external libraries - PPL and CLooG-PPL. The former is in portage and the latter can be found in my overlay.
I haven't done any testing except to make sure it builds properly, and I'm not planning on using it myself, so you're on your own if you break something.
Enjoy.
|
December 15th, 2008
06:15 pm - package testing
Recently, Diego brought up a subject that I've been meaning to talk about for a while.
Besides arguing at people on mailing lists, the majority of my time in Gentoo is spent on gcc-porting work; basically, making sure that the packages in the tree build with the next upcoming GCC release. Right now we're working on getting stable ready for GCC 4.3 (huge thanks to everyone that's helped w/ this), and I've also been building the tree with 4.4. As I've mentioned here before, the 4.3 transition has been a bit of a bitch, and judging by Patrick and Diego's efforts that even now continue to unearth packages that are broken by 4.3 (and even 4.2 and 4.1(!)) we still have a long way to go.
Generally with 4.3, broken packages are immediately obvious as the vast majority of errors happen at compile time (usually missing header includes). For whatever reason, however, with 4.4 I've found the majority of issues I've hit have not exposed themselves during the compile, but later at runtime. Because of this, I've become increasingly dependent on package testsuites to catch these errors. Unfortunately, the state of FEATURES=test has been and continues to be a pet-peeve of mine - more-so now than ever.
I keep a running list of testsuites that are known to be broken so I can disable tests on a per-package basis with an ugly hack*. I don't have access to my laptop at the moment, but last I remember it was over 40 pkgs. I have 19 masked here on the desktop but I'm in the process of rebuilding it as a stable box and don't have a lot of stuff installed yet.
Now I don't mind finding these and filing bugs. The more of this stuff that gets fixed, the less trouble for me and for everyone else in the long run. But I do end up spending a lot of time chasing down failures, determining if they're caused by GCC or some unrelated error, checking if they've been reported or not, seeing if it's an upstream problem or something Gentoo-specific, tracking down patches, etc. etc. On my first run of building @system with 4.4, I ended up with ~15-20 failed testsuites. After I spent a couple days weeding out the failures already reported and filing bugs for those that weren't, I was left with 2 packages that were actual errors caused by GCC 4.4 - glib and flex (and a handful of stuff broken due to glib).
This can get kinda frustrating.
I'm not sure what the point of this post is, except to rant I guess. It would definitely help if people took testsuites seriously (though this has gotten much better over time). If your testsuite fails, report it upstream. If it's Gentoo-specific, fix it or RESTRICT tests if you can't. Run with FEATURES="test" and report the failures you find. I think the end result of doing these things will be a more robust and stable tree, which is good for everyone.
Every so often someone starts a thread on g-dev about enabling tests by default. But until these tests actually /work/ they're worse than useless - it just perpetuates the idea that testsuites are pointless and encourages people to turn them off.
Enabling them for the dev profiles on the other hand...
* kali ~ # cat /etc/portage/env/media-libs/gstreamer-0.10.21
FEATURES=" ${FEATURES}"
FEATURES=${FEATURES/ test/}
Zac has shown me a nicer approach in bug #44796 that I haven't gotten around to scripting yet.
|
December 9th, 2008
05:35 pm - gone
offline until i can find a replacement ac adaptor for the laptop. if you need me to see something, send it to gmail. i can check that at school.
|
November 22nd, 2008
10:43 pm - closest book meme
sure, why not.
* Grab the nearest book.
* Open it to page 56.
* Find the fifth sentence.
* Post the text of the sentence in your journal along with these instructions.
* Don’t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.
Page 56 doesn't have five sentences so, this is from page 57.
"While anarchy can often turn a humdrum weekend into something unforgettable, eventually the mob must be kept from stealing the conch and killing Piggy."
America (the book)
|
October 30th, 2008
11:13 pm - gcc-4.4 shorter-list
after a bit of detective work i was able to whittle down the gcc-4.4 failure list to just 5 packages:
* The following packages have failed to build or install:
*
* ('ebuild', '/', 'dev-util/pkgconfig-0.23', 'merge')
ICE - haven't investigated
* ('ebuild', '/', 'sys-devel/flex-2.5.35', 'merge')
https://sourceforge.net/tracker2/?func=detail&atid=618177&aid=2178663&group_id=97492
* ('ebuild', '/', 'sys-apps/tcp-wrappers-7.6-r8', 'merge')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
* ('ebuild', '/', 'dev-lang/perl-5.8.8-r5', 'merge')
segfault
* ('ebuild', '/', 'dev-libs/cyrus-sasl-2.1.22-r2', 'merge')
digestmd5.c:4037:15: error: #elif with no expression
('ebuild', '/', 'dev-libs/glib-2.18.2', 'merge')
segfault
next up - xorg, gnome, and kde.
|
October 25th, 2008
05:38 pm - 4.4 shortlist
package failures w/ gcc-4.4 on a barebones headless system:
gcc version 4.4.0-pre9999 built 20081025 (Gentoo SVN ebuild) rev. 141361 ()
dev-lang/perl-5.8.8-r5
dev-libs/cyrus-sasl-2.1.22-r2
dev-libs/glib-2.18.1
dev-python/dbus-python-0.83.0
dev-python/pygobject-2.14.2
dev-util/pkgconfig-0.23
net-misc/curl-7.18.2
sys-apps/busybox-1.12.0
sys-apps/coreutils-6.12-r2
sys-apps/dbus-1.2.3-r1
sys-apps/hal-0.5.11-r3
sys-devel/automake-1.9.6-r2
sys-devel/flex-2.5.35
sys-devel/gdb-6.8-r1
some of these may be testsuites that fail even with other versions (i'm looking at you coreutils and automake). i haven't looked at all of them yet but most i have are segfaults. only one (flex) is a bug, which i've already poked upstream about.
much less work than 4.3 so far. :D
|
October 20th, 2008
06:14 pm - lzma in system packages
here's a fun trap. if you're going to be changing major compiler versions often, you'll want to build lzma-utils with the nocxx flag enabled so you don't find yourself unable to unpack certain patch tarballs when you switch back.
i still don't understand why we even bother with lzma...
|
October 19th, 2008
11:45 pm
so with midterms looming, i did the sensible thing and began gcc-4.4 testing. so far a couple bugs in @system - flex needs a header addition, perl ICEs, and some testsuite failures I have to look at. worlds apart from when 4.3 was at the same stage.
speaking of which, i'm looking at the god-awful job stabilizing 4.3 is going to be and involuntarily gagging. maybe if we wait another year enough 4.3 fixes will trickle down to stable on their own and we can avoid b.g.o imploding under the mass of another 500-bug gcc tracker.
i should also have a couple new (haha) mips boxes on the way soon, an octane and an octane2, to heat the apartment this winter. oh and maybe even keyword some things.
|
September 15th, 2008
10:10 pm - PS3 streamings
dear lazyweb,
i just discovered my laptop has no dvd burner (wtf?), and i don't really feel like going back and forth to the PS3 with a usb drive everytime i grab a new episode of something from bittorrent. can anyone recommend a DLNA / uPnP server (pref. already in portage) that i can use to just directly stream video from the laptop? i'm looking at mediatomb but have no idea what else is out there.
|
August 25th, 2008
10:08 pm - offline now until Sept ??
i'll be effectively offline from now until i get set up at the new apartment in Moose Jaw sometime in the next couple weeks (i imagine it'll take a while for them to hook me up, being the back to school rush).
|
May 23rd, 2008
05:20 pm
My O2 box seems to have broken. It continually reboots, or if it gets through bootup, shuts down at the first hint of load. I might try to find another, but considering I'll be moving in August I may wait until after that. I need to figure out how to handle tuition first too.
I've been working on font stuff lately. Right now my aim is to support as many languages as possible and make sure we have coverage of the majority of the unicode space. Last weekend I focused on truetype/opentype stuff, latin, european, arabic, and african. This weekend I'll cover bitmaps, indic, and cjk. My goal is to be able to display all the spam in my inbox in its native script. ;)
(BTW, if there is a font you /need/ to be able to display your native language, and we don't have it in portage, let me know.)
|
April 30th, 2008
11:34 am - Why mozilla needs a freedesktop.org liason
So I finally got fed up with fonts on half the sites i visit (including LJ) being gargantuan in Firefox 3. I managed to track it down to this bug [https://bugzilla.mozilla.org/show_bug.cgi?id=384090].
Yay, it's fixed!
Then I read this gem:
"Well, the correct way to set font DPI on the Linux desktop is with the
/desktop/gnome/font_rendering/dpi gconf key."
*sigh*
|
April 29th, 2008
12:00 pm - note to self...
...posting to mailing lists while on significant doses of painkillers is not always the best idea.
|
|
|