Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to make ALSA relocatable in the filesystem? #34

Closed
probonopd opened this issue Mar 7, 2020 · 4 comments
Closed

How to make ALSA relocatable in the filesystem? #34

probonopd opened this issue Mar 7, 2020 · 4 comments

Comments

@probonopd
Copy link

probonopd commented Mar 7, 2020

We want to bundle a private copy of ALSA with our application, so that the ALSA from the Linux distribution is not used at all. Yet it seems ALSA is relying on some absolute paths compiled in with no clear way to pass in a different location for ALSA at runtime.

How to do this?

Use case:
As an application developer, I want to ship my application together with all dependencies. This bundle is using musl libc, ships its own musl libc and runtime, and it is intended to also run on glibc-based systems.

Reference:
mumble-voip/mumble#3959 (comment)

@probonopd
Copy link
Author

It appears that https://github.com/flatpak/freedesktop-sdk-images/blob/1.6/alsa-lib-plugin-path.patch might be addressing this?

perexg added a commit that referenced this issue Jun 4, 2020
In commit b906db1, the snd_dlopen()
implements the automatic lookup to the ALSA_PLUGIN_DIR directory.
It is not necessary to add the absolute paths in callers now.

The plugin names are also searched in ld.so.conf paths as the fallback now,
but it should not be a big problem.

BugLink: #34
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
perexg added a commit that referenced this issue Jun 4, 2020
BugLink: #34
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
@perexg
Copy link
Member

perexg commented Jun 4, 2020

Commited to master.

@bkuhls
Copy link
Contributor

bkuhls commented Jun 13, 2020

This patch breaks building alsa-lib with uClibc:

dlmisc.c:79:51: error: ‘RTLD_DL_LINKMAP’ undeclared (first use in this function)
   if (dladdr1(&snd_dlpath, &info, (void**)&links, RTLD_DL_LINKMAP) == 0)
dlmisc.c:81:38: error: ‘RTLD_DI_ORIGIN’ undeclared (first use in this function)
   if (links != NULL && dlinfo(links, RTLD_DI_ORIGIN, origin) == 0) {

RTLD_DL_LINKMAP & RTLD_DI_ORIGIN, are unsupported on uClibc:
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/include/dlfcn.h#n106

@perexg
Copy link
Member

perexg commented Jun 13, 2020

This patch breaks building alsa-lib with uClibc:

dlmisc.c:79:51: error: ‘RTLD_DL_LINKMAP’ undeclared (first use in this function)
   if (dladdr1(&snd_dlpath, &info, (void**)&links, RTLD_DL_LINKMAP) == 0)
dlmisc.c:81:38: error: ‘RTLD_DI_ORIGIN’ undeclared (first use in this function)
   if (links != NULL && dlinfo(links, RTLD_DI_ORIGIN, origin) == 0) {

RTLD_DL_LINKMAP & RTLD_DI_ORIGIN, are unsupported on uClibc:
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/include/dlfcn.h#n106

Why uclibc build defines __GLIBC__ ?

#ifdef __GLIBC__

If you have a better way to check non-glibc build, we can change it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants