Well, today's lesson was about libtool and what those curious .la files are for. I decided to go through the packages made so far (a couple of dozen) and start to clean out all the dirty hacks that I did to get started while I was learning. For example, I made a ~/.rpmmacros setting "crosspath" to set the active crosscompiler base path instead of embedding it in the spec files all over the place, and when I got started I embedded the literal path to the devel-filesystem directory (you install package-devel packages here so that other packages can link to those libs during crosscompile), now I use a relative path. While I was at it, I decided to fix the few packages that I left getting stored into /usr/local instead of /usr, well, they ended up like that because I didn't know what --bindir= was for in ./configure at that time. Curl and PHP fell into this category. Then I remembered that I had not understood how to link PHP to curl libraries at that time either and I could fix that too now. (When you meet something as big as ./configure and crosscompiling and packaging all at the same time, it is a terrible struggle just to get through to a successful compile and corners get cut, but once the process is familiar it's embarrassing to go back and see what simple things need to be refactored from your early clueless threshing around.) Anyway I recooked curl and then did PHP. To my surprise PHP kicked out right at the last link stage, it had attempted to link the host /usr/lib/libcurl.so instead of the target-compiled ones which in my system are installed into ./rpm/BUILD/devel-filesystem/usr/lib (by doing an rpm -i on the -devel package with a fake root). I wandered around trying to understand this for a while changing env vars like LDFLAGS, but it was clear the -L path to my devel-filesystem tree had the right precedence and nothing was on the libtool commandline telling it to go to /usr/lib. In the end as a test I moved my local /usr/lib/libcurl.so to /root and tried again -- this time it linked fine using target libs as intended. Strange because it proved it was some kind of precedence issue, looking in local /usr/lib first and then using the right path if that didn't exist. But I noticed a warning... it said that /blah/blah/libcurl.la "had moved". I had a look in the la file -- it is actually pretty cool, it is a text file that seems to be generated at library link time and contains paths to the libraries that it linked in. In this case curl has openssl in it, so that was shown and was correct. BUT what is this at the bottom? # Directory that this library needs to be installed in: libdir='/usr/lib' Hm a bit suspicious since my problems come from /usr/lib. I changed the path to point to my devel-filesystem path, and the build completed correctly! I tried commenting out the libdir line in the .la file, but the link blows chunks complaining it can't find the "library name" of libcurl.la. So the only way forward to allow usage of libs in the crosscompile environment seems to be to add a sed line to mess with the libdir setting in the library .la file!