Yaourt stands for "Yet AnOther User Repository Tool", which is a terrible name, but it is very effective at its job. It makes the AUR significantly easier to work with, by giving a pacman-like interface that does everything pacman does, but adds the AUR as a source. This makes installing packages from the AUR as simple as installing packages from the core repository... usually.
Having fought with and failed to get NixNote installed by hand, I turned in frustration to yaourt, and was pleasantly surprised at how easy it was to use. I still don't trust it entirely, because I can't find much in the way of documentation about it, and there seems to be some contradictory information about whether it is safe to use it for non-AUR packages or not. But I suspect like any labor-saving tool, my comfort with it will come long before my understanding.
I installed yaourt in a very similar manner to my installation of libgcal and akonadi-googledata before. It relies on the package-query package in AUR, which therefore needs to be installed first. The following steps can also be found at yaourt's website:
$ cd ~/abs
$ wget http://aur.archlinux.org/packages/package-query/package-query.tar.gz
$ wget http://aur.archlinux.org/packages/yaourt/yaourt.tar.gz
$ tar xf package-query.tar.gz
$ tar xf yaourt.tar.gz
$ cd package-query
$ makepkg -si
$ cd ../yaourt
$ makepkg -si
Next is to install NixNote. In theory, all I should need to do is:
$ yaourt nixnote
And in theory, there is no difference between theory and practice. But in practice, there is (Yogi, or Al, or Jan). And so it is in this case. After a bunch of package downloading, configuring, and compiling -- all done by yaourt -- I finally get this error:
/usr/bin/ld: /caviar/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libm.a(k_standard.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/caviar/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libm.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libpng12.la] Error 1
make[1]: Leaving directory `/tmp/yaourt-tmp-mark/aur-libpng12/src/libpng-1.2.46'
make: *** [all] Error 2
Let's break this down, shall we?
- /usr/bin/ld - this is the linker reporting the error, which means that all the code has compiled just fine, and now the build system is trying to assemble it into an executable binary file.
- .../lib/libm.a(k_standard.o) - the failure occurred while linking the static library "libm.a" into the executable, specifically some reference inside the program module k_standard.c, it doesn't really matter what.
- relocation R_X86_64_32s against `.rodata' can't be used when making a shared object - I'm not really sure what is going on here, but I suspect it has something to do with some of the weirdnesses of working with 64-bit addressing within libraries that were written assuming a 32-bit world. This sort of thing happens far more often than it should.
- recompile with -fPIC - advice from the linker on how to solve this issue, I love it.
- .../lib/libm.a: could not read symbols: Bad value - probably caused by the previous error. Once something goes wrong in a build process, its effect usually cascades forward a ways before the build system stops.
- make...libpng12.la - we weren't even working on building NixNote, here, but libpng12, one of its dependencies. libpng is a library for manipulating PNG graphics, and the repository version of this library is at 1.4. NixNote is woefully out of date, though, and won't work with anything newer than the old 1.2 version of libpng, and this is that outdated library.
The -fPIC flag to the linker is a new one to me. Here's a man page reference, taken from man ld:
-f name : When creating an ELF shared object, set the internal DT_AUXILIARY field to the specified name. This tells the dynamic linker that the symbol table of the shared object should be used as an auxiliary filter on the symbol table of the shared object name.
This doesn't really clear it up much. Some more searching led me to some related content that implied that the "recompile with -fPIC" advice was actually suggesting that I recompile the math library libm, which is an integral part of the operating system (pun intended). This is probably not a great idea, so instead I'll try to disable the use of shared libraries and PIC (Position Independent Code). By the way, if you want more information about all these issues, read this and then explain it to me. ;-) Anyway, I want to adjust the build process of libpng12, which all starts with the same command:
$ yaourt nixnote
Except this time, I'll answer "yes" when it comes to the libpng12 PKGBUILD question. Within this file, I see a section called "build" contains the line:
./configure --prefix=/usr
This is a very standard way to get a Linux source package ready for building and installation, and the best place to make my change. Specifically, I'll change it to:
./configure --prefix=/usr --disable-shared --without-pic
And this time, it sailed right through, building and installing libpng12, and then building and installing NixNote successfully, even adding it to my KDE menu for me and everything. But when I try to run it:
$ nixnote
...
java.lang.UnsatisfiedLinkError: /tmp/QtJambi_mark_amd64_4.5.2_01_gcc-20090628-2055/lib/libQtGui.so.4: libpng12.so.0: cannot open shared object file: No such file or directory
This isn't a big surprise, since I did disable the building of the shared library libpng with that first additional flag. For some reason, it occurred to me to do a file search on my hard drive for libpng12, and lo and behold, there was a libpng12.so.0 sitting in the Dropbox application directory! Yoink...
$ sudo ln -s ~mark/.dropbox-dist/libpng12.so.0 /lib/libpng12.so.0
$ nixnote
Finally, I can enter my Evernote account details, synchronize my notes from their server, and I'm off to the races. It's kind of sad that I had to jump through so many hoops to get this installed when the right answer would be to update NixNote to use the latest (and fully supported) version of libpng. Maybe someday I'll look at how feasible doing that would be, but today I just want my software to work.
Almost there!
No comments:
Post a Comment