Libtool And .la Files Containing Non-Absolute Paths


Still Fresh
Feb 1, 2008
This has been driving me batty all night so hopefully someone sees something obvious I'm doing wrong and can send me on my way.

I'm working on compiling an up to date version of MPlayer since I can't get the one from the codec pack to play video. I'm using DJWillis's toolchain freshly installed from the instructions on his blog and by this point I got ffmpeg compiled successfully and I'm working to compile libass for subtitle support. Yes, I sourced the /usr/local/angstrom/arm/environment-setup file before doing any of this.

libass is configured as:
./ --prefix="/home/josh/dev/mplayer-build/build_libs" --enable-static --disable-shared --host=arm-angstrom-linux-gnueabi
I get all the way through make and it compiles all the source files with no problems until it gets to linking.
(... the rest of the successful parts of the compile are omitted ...)
  CC     ass_render_api.lo
  CC     ass_strtod.lo
../libtool: line 6396: cd: $SDK_PATH/$TARGET_SYS/usr/lib: No such file or directory
libtool: link: warning: cannot determine absolute directory name of `$SDK_PATH/$TARGET_SYS/usr/lib'
/bin/grep: $SDK_PATH/$TARGET_SYS/usr/lib/ No such file or directory
/bin/sed: can't read $SDK_PATH/$TARGET_SYS/usr/lib/ No such file or directory
libtool: link: `$SDK_PATH/$TARGET_SYS/usr/lib/' is not a valid libtool archive
make[2]: *** [] Error 1
make[2]: Leaving directory `/home/josh/dev/mplayer-build/libass/libass'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/josh/dev/mplayer-build/libass'
make: *** [all] Error 2

Investigating more closely, the various .la files in /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib all have dependency_libs defined containing the SDK path variables like -L$SDK_PATH/$TARGET_SYS/usr/lib.
What I'm pretty sure is happening here is that the libtool script is not doing the variable expansion on these. As a result, when the libtool script tries to determine the absolute directory name, it fails because it interprets these paths literally.

One solution I found to this was to write a script which would run sed on every .la file and permanently do the variable expansion. The other solution is to hack up the libtool script to eval the paths it finds so the variable expansion is done in the script. I was able to do this for the line 6396 error above and was successful, but I don't know where else in the script I need to do it (there are quite a few greps and seds in there). I'm not a fan of either of these options because they're quite hackish. Is there a better alternative?