compile problems

compile problems

[David Henderson]

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

Re: compile problems

[Adrian Pardini]

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

Re: compile problems

[David Henderson]

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

Re: compile problems

[Adrian Pardini]

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

Re: compile problems

[Adrian Pardini]

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

Re: compile problems

[David Henderson]

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

Re: compile problems

[David Henderson]

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

Re: compile problems

[Takashi Iwai]

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

Re: compile problems

[David Henderson]

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

Re: compile problems

[Takashi Iwai]

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

Re: 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@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

Re: compile problems

[Takashi Iwai]

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

Re: compile problems

[David Henderson]

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

Re: compile problems

[David Henderson]

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

Re: compile problems

[Takashi Iwai]

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

Re: 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@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

Re: compile problems

[Paul Menzel]

[-- 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 --]

Re: compile problems

[David Henderson]

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

compile problems

[jon doe]

please help

heres the error

make -C /lib/modules/2.6.27.3-indika/build
M=3D/home/jon/compat-wireless-2008-10-29 modules
make[1]: Entering directory `/usr/src/linux-2.6.27.3'
  CC      /home/jon/compat-wireless-2008-10-29/net/mac80211/main.o
/home/jon/compat-wireless-2008-10-29/net/mac80211/main.c: In function
=E2=80=98ieee80211_handle_filtered_frame=E2=80=99:
/home/jon/compat-wireless-2008-10-29/net/mac80211/main.c:435: error:
=E2=80=98struct sk_buff=E2=80=99 has no member named =E2=80=98requeue=E2=
=80=99
/home/jon/compat-wireless-2008-10-29/net/mac80211/main.c:437: error:
=E2=80=98struct sk_buff=E2=80=99 has no member named =E2=80=98requeue=E2=
=80=99
make[3]: *** [/home/jon/compat-wireless-2008-10-29/net/mac80211/main.o]
Error 1
make[2]: *** [/home/jon/compat-wireless-2008-10-29/net/mac80211] Error =
2
make[1]: *** [_module_/home/jon/compat-wireless-2008-10-29] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.27.3'
make: *** [modules] Error 2


--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compile problems

[Luis R. Rodriguez]

On Wed, Oct 29, 2008 at 7:49 PM, jon doe <mass.of.doughnuts@gmail.com> wrote:
> please help
>
> heres the error
>
> make -C /lib/modules/2.6.27.3-indika/build
> M=/home/jon/compat-wireless-2008-10-29 modules
> make[1]: Entering directory `/usr/src/linux-2.6.27.3'
>  CC      /home/jon/compat-wireless-2008-10-29/net/mac80211/main.o
> /home/jon/compat-wireless-2008-10-29/net/mac80211/main.c: In function
> 'ieee80211_handle_filtered_frame':
> /home/jon/compat-wireless-2008-10-29/net/mac80211/main.c:435: error:
> 'struct sk_buff' has no member named 'requeue'
> /home/jon/compat-wireless-2008-10-29/net/mac80211/main.c:437: error:
> 'struct sk_buff' has no member named 'requeue'
> make[3]: *** [/home/jon/compat-wireless-2008-10-29/net/mac80211/main.o]
> Error 1
> make[2]: *** [/home/jon/compat-wireless-2008-10-29/net/mac80211] Error 2
> make[1]: *** [_module_/home/jon/compat-wireless-2008-10-29] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.6.27.3'
> make: *** [modules] Error 2

The compat code for aggregation wasn't added yet, but it should now be
there thanks to Tim. Please grab new tarball and try that.

git-describe says:
v2.6.28-rc2-4159-g6c11cd2
wireless-testing latest tag:
master-2008-10-29
This is compat-release:
v1.1-1-g1818f32


  Luis

RE: Problems with AMD CFI chips

[mark.langsdorf]

> mark.langsdorf@amd.com said:
> >  The Flash bank is found correctly, and loads, and I can 
> > write to it.
> > However, when I boot from it, I can't seem to get it to 
> > commit writes- either creating new files or altering old
> > ones.  Once I reboot the device, my changes are gone.
> 
> Please check using the /dev/mtd0 device directly to see 
> whether your writes are 'taking'. 

	I can write to /dev/mtd0, the writes through the char
interface are definitely consistent over power-outs.  It's
only when I use jffs on /dev/mtdblock0 that I run into problems.

> What 'map' driver are you using?

	Modified version of physmap, since the flash banks are
physically mapped at 0x2000000 but I needed to partition them
because the BIOS and kernel image are also stored on the same
banks.

> for me on the iPAQ because I wasn't enabling the Vpp voltage
> during write cycles. Is this necessary on your targer?
> 
> Other than that, poke the author and/or look at the code 
> yourself to see what's happening. What interleave/buswidth
> are you using?

	Interleave 2, 4 byte buswidth, to support 2 16 bit chips.
Again, that all looks pretty consistent.

	I think it may be some kind of interaction with jffs,
because I've had limited success with creating directories 
and deleting files, but not consistently.  I'm not sure where
I should look in the jffs code to get more information, though,
and would appreciate some pointers.
	Also, when does jffs attempt to clean out the dirty
space?  thread_should_wake reports upwards of 2 megs of
dirty space, which is about 16 sectors and 14% of the available
memory.  I'd think that should get returned to the free list
much earlier, especially during the reboots.

-Mark Langsdorf
AMD, Inc.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Compile problems

[Gregory Schallert]

I am having a couple of problem compelling I think that it is fixed with
a patch.  I was wondering what is the syntax for applying the .patch
files?



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[David Woodhouse]

On Fri, 3 Nov 2000, Gregory Schallert wrote:

> I am having a couple of problem compelling I think that it is fixed with
> a patch.  I was wondering what is the syntax for applying the .patch
> files?

Something like 'patch -p0 < patchfile'

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Compile problems

[Jason Gunthorpe]

Hi all,

Just been working on getting the latest MTD cvs to compile on
2.3.99-pre8-rmk2 for an ARM platform.

There are a few issues it seems, someone should decide what they mean, I 
suppose..

1) Damn Odd compile errors

mtdcore.c:350: warning: `init_mtd' defined but not used
mtdcore.c:374: warning: `cleanup_mtd' defined but not used
{standard input}: Assembler messages:
{standard input}:6: Warning: Ignoring changed section attributes for
.modinfo

The first two are due to the init/cleanup functions being declared static.
The second two are due to gcc emitting some very odd assembly:

@ Generated by gcc 2.95.2 19991024 (release) for ARM/elf
        .file   "mtdcore.c"
gcc2_compiled.:
        .section .modinfo
        .previous
.section        .modinfo,"a",%progbits
        .align  2
        .type    __module_kernel_version,object
        .size    __module_kernel_version,32
__module_kernel_version:
        .ascii  "kernel_version=2.3.99-pre8-rmk2\000"
.section        .rodata
[...]

The '.section .modinfo\n.previous' comes from the kernel module.h header,
the second section declaration directly after comes from GCC.. I don't
recall seeing this when compiling the kernel proper, so maybe there is
something strange about the MTD stuff?

2) ioremap, memcpy_fromio, etc seem to be PCI things

Most of the low level drivers won't even compile, mostly because my ARM
arch doesn't have PCI or ISA io functions :> But reading around I think
the slram,vmax and oct drivers are wrong.. vmax and oct should
probably use the isa_* flavors of all the functions, and I don't know how
slram should try to portably access the end of memory, but ioremap
probably isn't it? 

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[David Woodhouse]

On Sat, 24 Jun 2000, Jason Gunthorpe wrote:

> Just been working on getting the latest MTD cvs to compile on
> 2.3.99-pre8-rmk2 for an ARM platform.

I've tested it on 2.4/ia32 and 2.2/ARM. Not yet 2.4/ARM although I didn't
expect it to break.


> 1) Damn Odd compile errors
> 
> mtdcore.c:350: warning: `init_mtd' defined but not used
> mtdcore.c:374: warning: `cleanup_mtd' defined but not used
> {standard input}: Assembler messages:
> {standard input}:6: Warning: Ignoring changed section attributes for
> .modinfo
> 
> The first two are due to the init/cleanup functions being declared static.

That's known and harmless. They're not unused; they're aliased. Consider
it a GCC bug and ignore it.

> The second two are due to gcc emitting some very odd assembly:
	<snip>
> 
> The '.section .modinfo\n.previous' comes from the kernel module.h header,
> the second section declaration directly after comes from GCC.. I don't
> recall seeing this when compiling the kernel proper, so maybe there is
> something strange about the MTD stuff?

Not knowingly. Prod rmk or a gcc hacker. Also try cutting out stuff till
it goes away and work out exactly what's causing it. Do you have MTD_DEBUG
defined?

> 2) ioremap, memcpy_fromio, etc seem to be PCI things
> 
> Most of the low level drivers won't even compile, mostly because my ARM
> arch doesn't have PCI or ISA io functions :> 

Ah - on mine they're defined to panic()

> But reading around I think the slram,vmax and oct drivers are wrong..
> vmax and oct should probably use the isa_* flavors of all the
> functions, and I don't know how slram should try to portably access
> the end of memory, but ioremap probably isn't it?

Yes, vmax and oct should use the isa_ functions. Also, they should only be
configurable if CONFIG_ISA is set, if they're ISA boards.

slram I haven't looked at for a while, and I'm not sure what to do with it
either. 

To get the DiskOnChip drivers to work, just stick #ifndef __arm__ around:

#define ReadDOC(adr, reg)      readb(((unsigned long)adr) + DoC_##reg)
#define WriteDOC(d, adr, reg)  writeb(d, ((unsigned long)adr) + DoC_##reg)

... in include/linux/mtd/doc2000.h and #else the appropriate alternative.
Also ifdef the ioremap in docprobe.c and the iounmap in docprobe.c and
doc200[01].c


-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[Jason Gunthorpe]

On Sun, 25 Jun 2000, David Woodhouse wrote:

> > Just been working on getting the latest MTD cvs to compile on
> > 2.3.99-pre8-rmk2 for an ARM platform.
 
> I've tested it on 2.4/ia32 and 2.2/ARM. Not yet 2.4/ARM although I didn't
> expect it to break.

Well, I am also using a very odd arm sub-arch (cl-ps7500fe)

> > The first two are due to the init/cleanup functions being declared static.
> 
> That's known and harmless. They're not unused; they're aliased. Consider
> it a GCC bug and ignore it.

Thats what I thought.. I wonder has anyone told the GCC people?
 
> > The '.section .modinfo\n.previous' comes from the kernel module.h header,
> > the second section declaration directly after comes from GCC.. I don't
> > recall seeing this when compiling the kernel proper, so maybe there is
> > something strange about the MTD stuff?
> 
> Not knowingly. Prod rmk or a gcc hacker. Also try cutting out stuff till
> it goes away and work out exactly what's causing it. Do you have MTD_DEBUG
> defined?

No, I don't think I do. I'll ask on the ARM list later then..
 
> > 2) ioremap, memcpy_fromio, etc seem to be PCI things
> > 
> > Most of the low level drivers won't even compile, mostly because my ARM
> > arch doesn't have PCI or ISA io functions :> 
> 
> Ah - on mine they're defined to panic()

Heh, on my arch they just aren't defined :| Thats OK, I shouldn't be
compiling most of those drivers as they are i386 only (particularly the
SBC drivers)
 
> Yes, vmax and oct should use the isa_ functions. Also, they should only be
> configurable if CONFIG_ISA is set, if they're ISA boards.

Well, they are SBCS, so they should be available if CONFIG_ISA and
whatever the I386 test is set.
 
> To get the DiskOnChip drivers to work, just stick #ifndef __arm__ around:
> 
> #define ReadDOC(adr, reg)      readb(((unsigned long)adr) + DoC_##reg)
> #define WriteDOC(d, adr, reg)  writeb(d, ((unsigned long)adr) + DoC_##reg)
> 
> ... in include/linux/mtd/doc2000.h and #else the appropriate alternative.
> Also ifdef the ioremap in docprobe.c and the iounmap in docprobe.c and
> doc200[01].c

Having not looked at it, shouldn't the DOC access be regulated to a lower
level driver, like we have for the other flash stuff? If I were to slap a
DOC on an ARM board here it would probably have quite different access (32
bit for one thing). 

BTW, I am almost finished redoing my JEDEC stuff to be more like your CFI
stuff [turns out my SIMM was made in 1995, no CFI] and adding support for
interleved and banked memories.. will send you a patch soon. 

I did add two new things to the struct map to make this possible:

  unsigned bus_width;    // Number of data bits between host<->memregion
  unsigned long bank_size;   // Bytes in a bank. size = bank_size*bank_count

Both should always be settable by a low level driver, they are determined
by the eletrical connections of the device. bus_width is 8/16/32 and
bank_size is to basically support FLASH SIMMS which have 4 chip select
lines E[0-4] that select 1 of 4 banks of chips. It is expected that these
lines will be driven by the host at some specific address interval, mine
is 4Meg. So if you have less than 4 meg of chips you end up with spaces
between them and the driver has to advoid them and probe differently. 

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[David Woodhouse]

jgg@deltatee.com said:
>  Having not looked at it, shouldn't the DOC access be regulated to a
> lower level driver, like we have for the other flash stuff? If I were
> to slap a DOC on an ARM board here it would probably have quite
> different access (32 bit for one thing).  

Urgh. You might be right. Which is a shame because the current map setup 
doesn't handle the type of access that the DiskOnChip requires very nicely. 
Where it's reading 512 consecutive bytes out of the same port on the ASIC, 
it'd be 512 indirect function calls in a tight loop. Maybe we need an extra 
method in the map object if we're going to do that.

Lets try to avoid it for a while - presumably anyone who adds a DiskOnChip 
to an ARM system will do the same thing, so the ReadDOC and WriteDOC macros 
can be defined accordingly for ARM systems, and we'll bury our head in the 
sand for a little longer until some nutter comes up with a second method 
for a given architecture and we can no longer ifdef it. :)


jgg@deltatee.com said:
> I did add two new things to the struct map to make this possible:
>   unsigned bus_width;

Good point.

>   unsigned long bank_size;   // Bytes in a bank. size = bank_size*bank_count 

> So if you have less than 4 meg of chips you end up with spaces between
> them and the driver has to advoid them and probe differently.  

I have the same - 16Mb at 0x0, 16Mb at 0x2000000. But it's aliases, not 
spaces between them - just to make it more interesting. (And I was told it 
wouldn't be like that, so when I erased the 'second' chip at 0x1000000 I 
was actually erasing the firmware... :) 

I changed the VM setup to present them to the CPU contiguously. If that wasn't
possible, I'd have done the mask-and-shift necessary in the map driver. Is
it really necessary for the user to know about it? Surely it's just a
physical detail of the wiring?




--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[Jason Gunthorpe]

On Mon, 26 Jun 2000, David Woodhouse wrote:

> Lets try to avoid it for a while - presumably anyone who adds a DiskOnChip 
> to an ARM system will do the same thing, so the ReadDOC and WriteDOC macros 
> can be defined accordingly for ARM systems, and we'll bury our head in the 
> sand for a little longer until some nutter comes up with a second method 
> for a given architecture and we can no longer ifdef it. :)

Okay, I'm not sure how popular DOC will be long term, thought their new
parts look kind of nice.. (small physical size and all)

> >   unsigned long bank_size;   // Bytes in a bank. size = bank_size*bank_count 

> > So if you have less than 4 meg of chips you end up with spaces between
> > them and the driver has to advoid them and probe differently.  
> 
> I have the same - 16Mb at 0x0, 16Mb at 0x2000000. But it's aliases, not 
> spaces between them - just to make it more interesting. (And I was told it 
> wouldn't be like that, so when I erased the 'second' chip at 0x1000000 I 
> was actually erasing the firmware... :) 

Yes, aliases is what it always should be, in fact my driver counts on it
:> How it works is they just connect up the necessary address lines and
use the E[0-4] lines as chip selects. Chip selects are generated by a PLD.
I expect more elaborate systems will have a PLD that has configurable bank
size..

Usually I think that anything that is not perfectly linear is either that
way because someone is abusing CPU CS lines, or because they expect to
have the option to install larger chips in future.

> I changed the VM setup to present them to the CPU contiguously. If that wasn't
> possible, I'd have done the mask-and-shift necessary in the map driver. Is

That is only possible if you know the chip size in advance, or are willing
to add APIs to dynamically remap this stuff. I have here a socket, you can
plug whatever you want into it. If that happens to be anything less than a
32 meg part you end up with holes. Plus, on my ARM board the mapping of
the flash is done on boot, I'm not sure it can be remapped..

Fortunately it turns out to be not too much code to worry about.

> it really necessary for the user to know about it? Surely it's just a
> physical detail of the wiring?

If the mapping driver knows the chip size in advance it can remap as you
have done and set that value to the mapping size, otherwise I think it is
necessary to have support in a higher layer. It is definately required for
detection, and is only a minor amount of code for
writing/eraseing/reading. For reading I made a seperate function for
speed, the other functions are already so slow nobody will notice :>

Ideally, if the mapping driver can remap then after the detection sequence
it would remap it as necessary and re-detect to get a linear view. Some
drivers (such as windowed ones, maybe this ARM one too) can't remap even
if they wanted to.

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[David Woodhouse]

jgg@deltatee.com said:
>  BTW, I am almost finished redoing my JEDEC stuff to be more like your
> CFI stuff [turns out my SIMM was made in 1995, no CFI] and adding
> support for interleved and banked memories.. will send you a patch
> soon. 

Like my CFI stuff will be when I've finished it, I assume - not like it is 
at the moment - busy waiting and only detecting one chip in a mapping :)

I'm going to protect each chip with its own spinlock, and make erases 
asynchronous. I was hoping to do that last week, but it doesn't seem to 
have happened. Maybe this week.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Compile problems

[Jason Gunthorpe]

On Mon, 26 Jun 2000, David Woodhouse wrote:

> Like my CFI stuff will be when I've finished it, I assume - not like it is 
> at the moment - busy waiting and only detecting one chip in a mapping :)

Hopefully close :> I have the whole thing done, just need to test it now.
 
> I'm going to protect each chip with its own spinlock, and make erases 
> asynchronous. I was hoping to do that last week, but it doesn't seem to 
> have happened. Maybe this week.

If you do that can you do the JEDEC one too? I'm not at all sure how
to ho about doing that, but the flash_erase function is split just so
someone eventually could. 

Seperate spinlocks is possible too, each chip has it's own little struct
that can be locked off.

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org