[alsa-devel] additional problem

alex dot baldacchino dot alsasub at gmail dot com alex.baldacchino.alsasub at gmail.com
Thu Jun 30 19:34:22 CEST 2011


2011/6/29 David Henderson <dhenderson at digital-pipe.com>:
> Hi gang!  I've successfully been able to compile the alsa-utils package
> with the "--with-alsa-inc-prefix=/opt/staging/alsa/var/share/include
> --with-alsa-prefix=/opt/staging/alsa/lib", but the problem I'm having
> now is that the compiled binaries are looking for those directories
> during run-time and not just compile-time.  Does anyone have any
> thoughts on using those directories for package creation, but that the
> software doesn't use the '/opt/staging/alsa' prefix during run-time?
>
> Thanks,
> Dave
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>


Do you have a full build environment under /opt/staging? If so, you
could try to chroot there and configure your software 'normally'
instead of passing those parameters... or passing those paths starting
from '/' instead of '/opt/staging/' (provided that the final
installation will match them, e.g. binaries will look into
'/var/share/include' and /lib)... it might work...

If you missed something from the 'real' environment, you could try
(before chroot'ing) to create (hard) links to those paths within a
'local' dir (e.g. create dir /opt/staging/extern/ and therein link to
/bin, /sbin, /usr/bin etc.) then arrange to have these 'local' paths
listed (after chroot'ing) at the end of your PATH env variable. You
would need at least a working /opt/staging/bin/sh and perhaps some
symlinks, such as a 'lib' pointing to "/alsa/lib" and a 'var' pointing
to "/alsa/var", but if such names exist as directories you could need
links to each file/subdirectory, perhaps a script could help you
creating them on the fly (after chroot'ing) once you knew what you
need (e.g. if you need stuff in alsa/var/share/include, arrange your
script to work, for instance, with 'alsa' as first parameter and
var/share/include as second parameter, then mkdir -p var/share/include
and symlink to alsa/var/share/include/<whatever> - if there are
subdirs therein, mkdir -p instead of symlinking and move in depth,
just in case you needed something from a different
<name>/var/share/include/<inner_name>/*). You might also need
(sym)links to stuff in extern/<somedir>/ - such a 'dynamic' build
environment may become hard to create and handle, more than a full
build env for creating a distro from scratch, unless that's what
you're doing, just using some code and configurations from an existing
distro, in which case maybe you have a full build env yet, so just
chroot, compile and install everything both with DESTDIR (to create a
package later) and 'normally' (to have include and lib files easy to
reuse to match dependencies for building other software).

Or... put your hands into alsa-utils'
autogen/automake/configure/script files (if you want an automated
process to reuse, or just modify the generated Makefile, if enough)
and customize them to achieve what you aim, e.g. setting different -L
and -rpath wherever needed, or set and export a global LDFLAGS, taking
care to include every library needed and correct paths (use the
generated Makefile as a hint), again with different -L and -rpath...
or perhaps all you need could be setting the final dirs to look into
at runtime in LD_RUN_PATH, in which case you could configure your
build as you've done successfully until now, then export (for
instance) LD_RUN_PATH=/lib (use the correct path, if you need to
include more than one path for shared objects, separate them with a
colon, e.g. LD_RUN_PATH=/lib:/var/lib - if I didn't misunderstand, you
have some stuff in /var that usually is in /usr/*), then make etc. The
latter choice might be the easier, so give it a try, but might not
work if your generated Makefile contains -rpath in LDFLAGS...

Regards.

Alex


More information about the Alsa-devel mailing list