[alsa-devel] compile problems

[David Henderson]

On 06/27/2011 12:07 PM, Takashi Iwai wrote:
> At Mon, 27 Jun 2011 11:31:18 -0400,
> David Henderson wrote:
>> On 06/27/2011 11:20 AM, Takashi Iwai wrote:
>>> At Mon, 27 Jun 2011 09:56:37 -0400,
>>> David Henderson wrote:
>>>> On 06/27/2011 09:35 AM, Adrian Pardini wrote:
>>>>> On 27/06/2011, David Henderson<dhenderson at digital-pipe.com>    wrote:
>>>>> [...]
>>>>>> checking for libasound headers version>= 1.0.16... not present.
>>>>>> configure: error: Sufficiently new version of libasound not
>>>>>> found.
>>>>>>
>>>>>>
>>>>>> Seeing as how this is a staging directory and not
>>>>>> the actual place the package is being installed to, I'm having the afore
>>>>>> mentioned problem because the alsa-utils package is looking under /...
>>>>>> for the header files instead of the /opt/staging/alsa/... directory.  Is
>>>>>> there a compile-time parameter that I can use so that alsa-utils looks
>>>>>> in the staging directory for the header files - just during the compile
>>>>>> phase?
>>>>> Hi Dave, try giving --with-alsa-inc-prefix=/opt/staging/alsa to the
>>>>> configure script.
>>>>>
>>>>>
>>>> Thanks for the help Adrian.  I tried passing that parameter to the
>>>> configure script and here's the below output:
>>>>
>>>> checking for a BSD-compatible install... /usr/bin/install -c
>>>> checking whether build environment is sane... yes
>>>> checking for gawk... no
>>>> checking for mawk... mawk
>>>> checking whether make sets $(MAKE)... yes
>>>> checking whether NLS is requested... yes
>>>> checking for msgfmt... /usr/bin/msgfmt
>>>> checking for gmsgfmt... /usr/bin/msgfmt
>>>> checking for xgettext... /usr/bin/xgettext
>>>> checking for msgmerge... /usr/bin/msgmerge
>>>> checking for style of include used by make... GNU
>>>> checking for gcc... gcc
>>>> checking for C compiler default output file name... a.out
>>>> checking whether the C compiler works... yes
>>>> checking whether we are cross compiling... no
>>>> checking for suffix of executables...
>>>> checking for suffix of object files... o
>>>> checking whether we are using the GNU C compiler... yes
>>>> checking whether gcc accepts -g... yes
>>>> checking for gcc option to accept ISO C89... none needed
>>>> checking dependency style of gcc... gcc3
>>>> checking build system type... i686-pc-linux-gnu
>>>> checking host system type... i686-pc-linux-gnu
>>>> checking for ld used by GCC... /usr/bin/ld
>>>> checking if the linker (/usr/bin/ld) is GNU ld... yes
>>>> checking for shared library run path origin... done
>>>> checking for CFPreferencesCopyAppValue... no
>>>> checking for CFLocaleCopyCurrent... no
>>>> checking for GNU gettext in libc... yes
>>>> checking whether to use NLS... yes
>>>> checking where the gettext function comes from... libc
>>>> checking for cross-compiler... gcc
>>>> checking for gcc... (cached) gcc
>>>> checking whether we are using the GNU C compiler... (cached) yes
>>>> checking whether gcc accepts -g... (cached) yes
>>>> checking for gcc option to accept ISO C89... (cached) none needed
>>>> checking dependency style of gcc... (cached) gcc3
>>>> checking for a BSD-compatible install... /usr/bin/install -c
>>>> checking whether ln -s works... yes
>>>> checking for ALSA CFLAGS...  -I/opt/staging/alsa
>>>> checking for ALSA LDFLAGS...  -lasound -lm -ldl -lpthread
>>>> checking for libasound headers version>= 1.0.16... not present.
>>>> configure: error: Sufficiently new version of libasound not found.
>>>>
>>>> I've double checked that the header files are present:
>>>> $ ls -1 /opt/staging/alsa/var/share/include/alsa/
>>> Pass the root path to alsa/*.h to --with-alsa-inc-prefix option, i.e.
>>> in your case, it's /opt/staging/alsa/var/share/include.
>>>
>>> But, the path is really odd and almost kidding (/share under
>>> /var...?)  Is it really correct?
>>>
>>>
>>> Takashi
>> Thanks for the additional help Takashi!  I've tried that as well without
>> any luck - still errors out at the same place and with the same
>> message.
> Then you should check config.log at the place error occurred.
> It contains more details.
> I guess you'll have to pass also --with-alsa-prefix pointing to the
> path where your local libasound.so.2 is placed.
>
>>   I know that some of the paths are non-traditional, but there
>> were certain guidelines that had to be met with this custom distro.  As
>> a result, some of the directories had to get moved.  That shouldn't be
>> adding to the problem right?  Since we're telling configure exactly
>> where to locate the files...
> Well, it's still very strange path.  The share sub-directory
> definitely doesn't belong under /var.  I'd understand that
> /opt/staging/alsa is a prefix for some build-root.  But /var/share
> is weird.  If any, it should be /usr/share.
>
>
> Takashi

I checked in the log file, but I didn't notice anything that gave an 
indication as to the failure.  Is there any spot in particular to look 
as the log just ends with "configure: exit 1", but everything above it 
just appears to be bash-styled variable assignments.

I ended up using the following configure parameters, but with the same 
results:
    --with-alsa-inc-prefix=/opt/staging/alsa/var/share/include/alsa 
--with-alsa-prefix=/opt/staging/alsa/lib
and I've confirmed that the appropriate files reside in the passed 
directories.

Obviously the traditional directory layout is /usr/share, but the distro 
doesn't have a /usr directory.  As a result, the directories that were 
under that parent directory had to be moved.  The chosen spot for some 
of them was /var (although the header files could have been moved to 
/lib/... perhaps).  At any rate, that's where the files are located.

Dave