Re: alsa-lib: alsa.pc's Libs shouldn't contain -lm -ldl -lpthread

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



r10 kindsofpeople wrote:
> I'm further along on my goal, but now even more confused.
>
> Benoit's comment about 'plug-ins' sparked the thought that, since my
> interest is in midi, not audio, I could try --disable-pcm.  This
> turned out to be insufficient, but combined with --disable-mixer,
> alsa-lib now builds without the -ldl errors.
>
> This turned out to be a small victory, however.  When I try to link my
> application with the resulting asound library, I'm back to having
> pthread and dl undefined references, and also snd_pcm_async among
> others.  The application only makes 'snd_seq*' calls, but I haven't
> tried tracing them to see what they call.
>
> I'll try Benoit's suggestion of creating empty function calls, but my
> sense is that I'm missing something obvious.
you should just find snd_dl*() in alsa-lib code, and replace their
content by the behaviour you want.
i.e. :
 - on snd_dlopen() you should return a non zero value. Actually you
could (should) check what lib is tried to be opened, to be sure you are
not doing something stupid... if the lib which is trying to be opened is
asound, it's ok, if it's another, it should also be linked by alsa (or
preferably by your application). let's assume it is the libasound. You
just return something which is non-zero (because the return value is the
lib handle when dlopen is used, and a NULL value is an error case)
 - on snd_dlclose() you just do nothing and return 0 (which means
everything's ok)
 - on snd_dlsym you should return the function you've been asked (and
that is the tricky part, maybe an if .... else if .... should do it...)

check other snd_dl*() functions to know what has to be done... but i
don't think the whole stuff will be trivial :)

Hope i helped you a bit...

Ben

>
> John
>
>> From: Benoit Fouet <benoit.fouet@xxxxxxxxxxxxxx>
>> To: Takashi Iwai <tiwai@xxxxxxx>
>> CC: alsa-user@xxxxxxxxxxxxxxxxxxxxx
>> Subject: Re:  alsa-lib: alsa.pc's Libs shouldn't contain
>> -lm    -ldl -lpthread
>> Date: Tue, 21 Nov 2006 15:07:27 +0100
>>
>> Takashi Iwai wrote:
>> > At Tue, 21 Nov 2006 14:47:15 +0100,
>> > Benoit Fouet wrote:
>> >
>> >> Takashi Iwai wrote:
>> >>
>> >>> At Tue, 21 Nov 2006 07:34:07 -0600,
>> >>> r10 kindsofpeople wrote:
>> >>>
>> >>>
>> >>>> First, let me apologize a second time...I thought I had found
>> this thread on
>> >>>> Alsa-user, but in fact it was posted to alsa-cvslog.  I imagine
>> it was more
>> >>>> than a bit confusing without the context of the rest of the thread.
>> >>>>
>> >>>> The bulk of that message was:
>> >>>> -----------------------------------------
>> >>>> -lm -ldl -lpthread are _not_ needed in Libs (since the alsa
>> interface
>> >>>> doesn't depend on libm, libdl or libpthread interface) and just
>> bring
>> >>>> unneeded dependencies. These should rather be put in Libs.private:
>> >>>>
>> >>>> Libs: -L${libdir} -lasound
>> >>>> Libs.private: -lm -ldl -lpthread
>> >>>>
>> >>>> See ALSA bug#2212 .
>> >>>> -----------------------------------------
>> >>>> and what follows after that was a difference file for making
>> these changes
>> >>>> to alsa.pc.in
>> >>>>
>> >>>> I'm trying to build the library to run on a uClinux target that
>> apparently
>> >>>> does not support libdl.  But when I build the alsa library with
>> >>>> --disable-shared --enable-static it still terminates when it
>> can't find
>> >>>> libdl.
>> >>>>
>> >>>>
>> >>> Do you mean the build of alsa-lib itself?  Then alsa.pc is
>> >>> irrelevant.  It must be in src/Makefile.am.  Try to remove -ldl
>> >>> there.
>> >>>
>> >>>
>> >> Will that change anything to his problem, though ?
>> >>
>> >
>> > Not sure.  I just gave the solution for the missing libdl because he
>> > never mentioned about the missing _functions_ during compilation.
>> >
>> >
>> >> I mean, won't he need to remove _the code_ that uses dl* functions
>> or,
>> >> at least, write something to remap dl* functions on functions ? Those
>> >> would just passes back a fake handle on dlopen, does nothing on
>> dlclose,
>> >> and gives back good functions on dlsyms calls.
>> >> (and if he doesn't use plugins, this should be ok)
>> >>
>> >> please tell me if i'm completely lost :)
>> >>
>> >
>> > If the system really provides no wrapper for dl*(), then yes, all
>> > dl*() should be removed.  It would be easy because basically all dl*
>> > calls are wrapped already by snd_dl*() functions inside alsa-lib.
>> >
>> >
>> > Takashi
>> >
>> that's what i thought of, thanks for confirmation :)
>>
>>
>> -------------------------------------------------------------------------
>>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>> _______________________________________________
>> Alsa-user mailing list
>> Alsa-user@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.sourceforge.net/lists/listinfo/alsa-user
>
> _________________________________________________________________
> Get the latest Windows Live Messenger 8.1 Beta version. Join now.
> http://ideas.live.com
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Alsa-user mailing list
> Alsa-user@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/alsa-user
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux