* compile problems @ 2011-06-27 13:09 David Henderson 2011-06-27 13:35 ` Adrian Pardini 0 siblings, 1 reply; 18+ messages in thread From: David Henderson @ 2011-06-27 13:09 UTC (permalink / raw) To: alsa-devel Greetings all! I've tried this question in the "alsa user" group without success, but was pointed in the direction of this mailing list. Currently I'm trying to compile the alsa packages to get it compiled for a custom Linux distro. I'm not having any problems compiling the alsa-lib package, but when I try to compile alsa-utils, I keep getting the following error: checking for libasound headers version>= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. To provide more details about the situation, I'm using an existing distro (Kubuntu 9.10) to build the alsa packages and are using the /opt/staging/alsa directory to compile and "install" to (using the DESTDIR parameter). 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? Thanks, Dave ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 13:09 compile problems David Henderson @ 2011-06-27 13:35 ` Adrian Pardini 2011-06-27 13:56 ` David Henderson 0 siblings, 1 reply; 18+ messages in thread From: Adrian Pardini @ 2011-06-27 13:35 UTC (permalink / raw) To: David Henderson; +Cc: alsa-devel On 27/06/2011, David Henderson <dhenderson@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. -- Adrian. http://ovejafm.com http://elesquinazotango.com.ar http://www.elarteylatecnologia.com.ar ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 13:35 ` Adrian Pardini @ 2011-06-27 13:56 ` David Henderson 2011-06-27 14:25 ` Adrian Pardini 2011-06-27 15:20 ` Takashi Iwai 0 siblings, 2 replies; 18+ messages in thread From: David Henderson @ 2011-06-27 13:56 UTC (permalink / raw) To: Adrian Pardini; +Cc: alsa-devel On 06/27/2011 09:35 AM, Adrian Pardini wrote: > On 27/06/2011, David Henderson<dhenderson@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/ alisp.h asoundef.h asoundlib.h conf.h control_external.h control.h error.h global.h hwdep.h iatomic.h input.h mixer_abst.h mixer.h output.h pcm_external.h pcm_extplug.h pcm.h pcm_ioplug.h pcm_old.h pcm_plugin.h pcm_rate.h rawmidi.h seq_event.h seq.h seqmid.h seq_midi_event.h sound/ timer.h version.h Thoughts? Thanks - Dave ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 13:56 ` David Henderson @ 2011-06-27 14:25 ` Adrian Pardini 2011-06-27 14:27 ` Adrian Pardini 2011-06-27 14:59 ` David Henderson 2011-06-27 15:20 ` Takashi Iwai 1 sibling, 2 replies; 18+ messages in thread From: Adrian Pardini @ 2011-06-27 14:25 UTC (permalink / raw) To: David Henderson; +Cc: alsa-devel On 27/06/2011, David Henderson <dhenderson@digital-pipe.com> wrote: > On 06/27/2011 09:35 AM, Adrian Pardini wrote: [...] >> 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 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/ My bad, here it works using ./configure --with-alsa-inc-prefix=/usr/include/alsa/ so I think you should use ./configure --with-alsa-inc-prefix=/opt/staging/alsa/var/share/include/alsa/. If you are not in a hurry I can try to replicate your directory structure when I get back to home. Also you may have to set the LDFLAGS environment variable to point to where your libraries are being installed under /opt -- Adrian. http://ovejafm.com http://elesquinazotango.com.ar http://www.elarteylatecnologia.com.ar ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 14:25 ` Adrian Pardini @ 2011-06-27 14:27 ` Adrian Pardini 2011-06-27 15:06 ` David Henderson 2011-06-27 14:59 ` David Henderson 1 sibling, 1 reply; 18+ messages in thread From: Adrian Pardini @ 2011-06-27 14:27 UTC (permalink / raw) To: David Henderson; +Cc: alsa-devel On 27/06/2011, Adrian Pardini <pardo.bsso@gmail.com> wrote: [...] > Also you may have to set the > LDFLAGS environment variable to point to where your libraries are > being installed under /opt --with-alsa-prefix looks more suitable. Maybe --with-alsa-prefix=opt/staging/alsa/var/ is all you need. -- Adrian. http://ovejafm.com http://elesquinazotango.com.ar http://www.elarteylatecnologia.com.ar ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 14:27 ` Adrian Pardini @ 2011-06-27 15:06 ` David Henderson 0 siblings, 0 replies; 18+ messages in thread From: David Henderson @ 2011-06-27 15:06 UTC (permalink / raw) To: Adrian Pardini; +Cc: alsa-devel On 06/27/2011 10:27 AM, Adrian Pardini wrote: > On 27/06/2011, Adrian Pardini<pardo.bsso@gmail.com> wrote: > [...] >> Also you may have to set the >> LDFLAGS environment variable to point to where your libraries are >> being installed under /opt > > --with-alsa-prefix looks more suitable. Maybe > --with-alsa-prefix=opt/staging/alsa/var/ is all you need. > Ok, I tried using this configure parameter instead of the --with-alsa-inc-prefix, but it's still bombing. I even tried compiling using each sub-directory as the value until the actual value was the entire path to where the header files were stored - each providing the same error message. One thing I did notice was by using the different configure parameter, the output was slightly different: using --with-alsa-inc-prefix=... <snip> checking for ALSA CFLAGS... -I/opt/staging/alsa/var 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. using --with-alsa-prefix=... <snip> checking for ALSA CFLAGS... checking for ALSA LDFLAGS... -L/opt/staging/alsa/var -lasound -lm -ldl -lpthread checking for libasound headers version >= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. Do I still need to adjust the LDFLAGS variable since it looks like it's passing that value to it already? Thanks, Dave ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 14:25 ` Adrian Pardini 2011-06-27 14:27 ` Adrian Pardini @ 2011-06-27 14:59 ` David Henderson 1 sibling, 0 replies; 18+ messages in thread From: David Henderson @ 2011-06-27 14:59 UTC (permalink / raw) To: Adrian Pardini; +Cc: alsa-devel On 06/27/2011 10:25 AM, Adrian Pardini wrote: > On 27/06/2011, David Henderson<dhenderson@digital-pipe.com> wrote: >> On 06/27/2011 09:35 AM, Adrian Pardini wrote: > [...] >>> 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 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/ > My bad, here it works using ./configure > --with-alsa-inc-prefix=/usr/include/alsa/ so I think you should use > ./configure --with-alsa-inc-prefix=/opt/staging/alsa/var/share/include/alsa/. > If you are not in a hurry I can try to replicate your directory > structure when I get back to home. Also you may have to set the > LDFLAGS environment variable to point to where your libraries are > being installed under /opt > Thanks for the continued help Adrian. I tried the adjusted configure parameter value, but it's still giving the same error message. Currently I'm in no rush, so let me know once you're able to get home. Also, if you need my compiled version of the alsa-lib package (or any other info), let me know. Thanks, Dave ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 13:56 ` David Henderson 2011-06-27 14:25 ` Adrian Pardini @ 2011-06-27 15:20 ` Takashi Iwai 2011-06-27 15:31 ` David Henderson 1 sibling, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2011-06-27 15:20 UTC (permalink / raw) To: David Henderson; +Cc: Adrian Pardini, alsa-devel 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@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 15:20 ` Takashi Iwai @ 2011-06-27 15:31 ` David Henderson 2011-06-27 16:07 ` Takashi Iwai 0 siblings, 1 reply; 18+ messages in thread From: David Henderson @ 2011-06-27 15:31 UTC (permalink / raw) To: Takashi Iwai; +Cc: Adrian Pardini, alsa-devel 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@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. 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... Dave ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 15:31 ` David Henderson @ 2011-06-27 16:07 ` Takashi Iwai 2011-06-27 16:30 ` David Henderson 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2011-06-27 16:07 UTC (permalink / raw) To: David Henderson; +Cc: Adrian Pardini, alsa-devel 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@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 16:07 ` Takashi Iwai @ 2011-06-27 16:30 ` David Henderson 2011-06-28 7:08 ` Takashi Iwai 2011-06-28 14:12 ` David Henderson 0 siblings, 2 replies; 18+ messages in thread From: David Henderson @ 2011-06-27 16:30 UTC (permalink / raw) To: Takashi Iwai; +Cc: Adrian Pardini, alsa-devel 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@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 16:30 ` David Henderson @ 2011-06-28 7:08 ` Takashi Iwai 2011-06-28 18:49 ` David Henderson 2011-06-28 14:12 ` David Henderson 1 sibling, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2011-06-28 7:08 UTC (permalink / raw) To: David Henderson; +Cc: Adrian Pardini, alsa-devel At Mon, 27 Jun 2011 12:30:40 -0400, 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@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 No, it must be /opt/staging/alsa/var/share/include Takashi ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-28 7:08 ` Takashi Iwai @ 2011-06-28 18:49 ` David Henderson 0 siblings, 0 replies; 18+ messages in thread From: David Henderson @ 2011-06-28 18:49 UTC (permalink / raw) To: Takashi Iwai; +Cc: Adrian Pardini, alsa-devel On 06/28/2011 03:08 AM, Takashi Iwai wrote: > At Mon, 27 Jun 2011 12:30:40 -0400, > 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@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 > No, it must be /opt/staging/alsa/var/share/include > > > Takashi Ok, I corrected the parameter value per your instructions above Takashi, but ended up with another compile error. I researched it online and found the resolution and it appears as though the source code compiled correctly. Thanks for your help (and everyone else who contributed)! Sincerely, Dave Henderson ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-27 16:30 ` David Henderson 2011-06-28 7:08 ` Takashi Iwai @ 2011-06-28 14:12 ` David Henderson 2011-06-28 14:20 ` Takashi Iwai 1 sibling, 1 reply; 18+ messages in thread From: David Henderson @ 2011-06-28 14:12 UTC (permalink / raw) To: Takashi Iwai; +Cc: Adrian Pardini, alsa-devel 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@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-28 14:12 ` David Henderson @ 2011-06-28 14:20 ` Takashi Iwai 2011-06-28 14:44 ` David Henderson 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2011-06-28 14:20 UTC (permalink / raw) To: David Henderson; +Cc: Adrian Pardini, alsa-devel 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@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-28 14:20 ` Takashi Iwai @ 2011-06-28 14:44 ` David Henderson 2011-06-28 14:55 ` Paul Menzel 0 siblings, 1 reply; 18+ messages in thread From: David Henderson @ 2011-06-28 14:44 UTC (permalink / raw) To: Takashi Iwai; +Cc: Adrian Pardini, alsa-devel 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@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-28 14:44 ` David Henderson @ 2011-06-28 14:55 ` Paul Menzel 2011-06-28 15:00 ` David Henderson 0 siblings, 1 reply; 18+ messages in thread From: Paul Menzel @ 2011-06-28 14:55 UTC (permalink / raw) To: alsa-devel [-- Attachment #1.1: Type: text/plain, Size: 503 bytes --] Am Dienstag, den 28.06.2011, 10:44 -0400 schrieb David Henderson: > On 06/28/2011 10:20 AM, Takashi Iwai wrote: > > At Tue, 28 Jun 2011 10:12:16 -0400, David Henderson wrote: > >> bump for help > > Did you read my last post? > Yes I did - as well as provide answers and questions in my reply above. Takashi pointed out an error in your command and you did not reply to this message as far as I remember. Please take a look at the Web archive and fix your mail setup. Thanks, Paul [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: compile problems 2011-06-28 14:55 ` Paul Menzel @ 2011-06-28 15:00 ` David Henderson 0 siblings, 0 replies; 18+ messages in thread From: David Henderson @ 2011-06-28 15:00 UTC (permalink / raw) To: alsa-devel On 06/28/2011 10:55 AM, Paul Menzel wrote: > Am Dienstag, den 28.06.2011, 10:44 -0400 schrieb David Henderson: >> On 06/28/2011 10:20 AM, Takashi Iwai wrote: >>> At Tue, 28 Jun 2011 10:12:16 -0400, David Henderson wrote: >>>> bump for help >>> Did you read my last post? >> Yes I did - as well as provide answers and questions in my reply above. > Takashi pointed out an error in your command and you did not reply to > this message as far as I remember. Please take a look at the Web archive > and fix your mail setup. > > > Thanks, > > Paul Ah! So he did! Must have gotten over looked - sorry! Dave ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-06-28 18:50 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-27 13:09 compile problems David Henderson 2011-06-27 13:35 ` Adrian Pardini 2011-06-27 13:56 ` David Henderson 2011-06-27 14:25 ` Adrian Pardini 2011-06-27 14:27 ` Adrian Pardini 2011-06-27 15:06 ` David Henderson 2011-06-27 14:59 ` David Henderson 2011-06-27 15:20 ` Takashi Iwai 2011-06-27 15:31 ` David Henderson 2011-06-27 16:07 ` Takashi Iwai 2011-06-27 16:30 ` David Henderson 2011-06-28 7:08 ` Takashi Iwai 2011-06-28 18:49 ` David Henderson 2011-06-28 14:12 ` David Henderson 2011-06-28 14:20 ` Takashi Iwai 2011-06-28 14:44 ` David Henderson 2011-06-28 14:55 ` Paul Menzel 2011-06-28 15:00 ` David Henderson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox