[alsa-devel] compile problems

[David Henderson]

On 06/28/2011 10:20 AM, Takashi Iwai wrote:
> At Tue, 28 Jun 2011 10:12:16 -0400,
> David Henderson wrote:
>> On 06/27/2011 12:30 PM, David Henderson wrote:
>>> 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
>> bump for help
> Did you read my last post?
>
>
> Takashi

Yes I did - as well as provide answers and questions in my reply above.

Dave