Re: [Alsa-user] First post
management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Hendersondhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configuremake. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... Great one less thing to compile! :) 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? Humm ! I don't really understand this method. In my opinion if you want to have a custom distro you first install a basic systme on a partition or in a directory. Once the basic system is installed (more or less the content of the lfs book) you simply chroot to this new system to install the rest of the stuff. Following this scheme there will be no problem. I did it many times ! It leads me to a more global question : you say you want to build a custom distro but do you have some kind of documentation to do that ? If you plan to do that on your own, it's a big deal ! Anyway I'll suggest you to have a look at the lfs book. It might be that the installation schedule suggested by the lfs team is not suitable for you but in my opinion it is better to check this point before reinventing the weel as we say in french ! Bests Pierre I guess the best way to describe what I'm trying to accomplish would be to look at it from a package maintainers perspective. They have to compile the source code into a staging directory so they can package the software. If they just ran the normal configure make make install, how would they know what files to include in the software package as they get spread through the FS? There has to be a staging directory that contains everything in isolation so that the package maintainer doesn't have to do so much overhead just to create a package, but when the package is installed, it works correctly (hence using DESTDIR and not --prefix). The problem I'm having, as stated, is that I think alsa is looking for header files or whatever under normal installation directories (e.g. /usr/... or /usr/local/...), but I need it to look under the staging directory (/opt/staging/alsa) since that's where the other matching compiled
Re: [Alsa-user] First post
of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Hendersondhender...@digital-pipe.comwrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... Great one less thing to compile! :) 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? Humm ! I don't really understand this method. In my opinion if you want to have a custom distro you first install a basic systme on a partition or in a directory. Once the basic system is installed (more or less the content of the lfs book) you simply chroot to this new system to install the rest of the stuff. Following this scheme there will be no problem. I did it many times ! It leads me to a more global question : you say you want to build a custom distro but do you have some kind of documentation to do that ? If you plan to do that on your own, it's a big deal ! Anyway I'll suggest you to have a look at the lfs book. It might be that the installation schedule suggested by the lfs team is not suitable for you but in my opinion it is better to check this point before
Re: [Alsa-user] First post
Hi, From: David Henderson dhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? Humm ! I don't really understand this method. In my opinion if you want to have a custom distro you first install a basic systme on a partition or in a directory. Once the basic system is installed (more or less the content of the lfs book) you simply chroot to this new system to install the rest of the stuff. Following this scheme there will be no problem. I did it many times ! It leads me to a more global question : you say you want to build a custom distro but do you have some kind of documentation to do that ? If you plan to do that on your own, it's a big deal ! Anyway I'll suggest you to have a look at the lfs book. It might be that the installation schedule suggested by the lfs team is not suitable for you but in my opinion it is better to check this point before reinventing the weel as we say in french ! Bests Pierre -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
From: James Shatto wwwshad...@gmail.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:36:59 -0500 A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com I suggested something intermediary : lfs or gentoo which are easily customizable. Pierre HTH, - James On 6/19/11, David Henderson dhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https
Re: [Alsa-user] First post
... or Sorcerer. James, you need to use the new system for compiling, not some other one. And how do you install applications on your custom system? By .deb packages?!?! Come on, this is not a custom system! This is exactly what Pierre said: reinventing the wheel. Like Ubuntu for Debian - who needs a copy when you have the original *for free*!!! You might be better using an already established distro, or if you want to go a little more in-deep, you might want to try a source based distro: that will definitely help you better understand the linux environment than what you are trying to do. There are already known dependencies that these distros will give you the choice to compile in or not. But doing that all by yourself is really an misuse of resources. If you do have that much free time, why don't you continue an already existing project? Join a project and ask for work: there will be so much interesting things you could do that will be over your head in less than a week after joining any open source project. Just ask! Keep up the good work! Work together! On 20.06.2011 18:55, Pierre Lorenzon wrote: From: James Shattowwwshad...@gmail.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:36:59 -0500 A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com I suggested something intermediary : lfs or gentoo which are easily customizable. Pierre HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http
Re: [Alsa-user] First post
not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
for alsa to see the source code of the custom distro's kernel version? C) So far, so good, but I'll keep that in mind. :) D) Thanks for the URL, but this is a project that I've wanted to do for the last 5-7 years and now I have the ability to do so. Not only that, but knowing details at this level of building an OS can also help with my job - so I get a two fold benefit. :) Otherwise, I'd definitely follow your advice! lol Thanks again for your help, I look forward to hearing back from you. Dave On 06/19/2011 04:36 PM, James Shatto wrote: A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's
Re: [Alsa-user] First post
Hi Ady, thanks for contributing to the conversation. :) I have a couple of questions based on your response below... Why do I need to use the new system for compiling? Isn't there normally 'configure' and 'make' options that allow for compiling on one system so the software can be packaged for installation on another system (e.g. DESTDIR)? The custom distro doesn't use .deb packages or any other existing package manager. I think James was referring to obtaining certain packages in Kubuntu (which is .deb based) so the alsa packages could be compiled on it and migrated over to the custom distro. I appreciate you guys steering me in the direction of using existing distro's, but there are several reasons to roll my own. And the reasons I don't want to join an existing project is because 1) there isn't another distro like the one I'm building as I've looked 2) instead of having to debate/argue with existing members over implementing changes, I can just re-route the time and headache into figuring out how to build my own. lol Some may consider this a misuse of resources, but if nobody was adventurous enough to break away from the norm, we've never have innovation. :) Again, I appreciate you guys trying to steer me in the direction most should go, but it isn't the route for everyone. :) Dave On 06/20/2011 04:06 AM, Ady Deac wrote: ... or Sorcerer. James, you need to use the new system for compiling, not some other one. And how do you install applications on your custom system? By .deb packages?!?! Come on, this is not a custom system! This is exactly what Pierre said: reinventing the wheel. Like Ubuntu for Debian - who needs a copy when you have the original *for free*!!! You might be better using an already established distro, or if you want to go a little more in-deep, you might want to try a source based distro: that will definitely help you better understand the linux environment than what you are trying to do. There are already known dependencies that these distros will give you the choice to compile in or not. But doing that all by yourself is really an misuse of resources. If you do have that much free time, why don't you continue an already existing project? Join a project and ask for work: there will be so much interesting things you could do that will be over your head in less than a week after joining any open source project. Just ask! Keep up the good work! Work together! On 20.06.2011 18:55, Pierre Lorenzon wrote: From: James Shattowwwshad...@gmail.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:36:59 -0500 A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com I suggested something intermediary : lfs or gentoo which are easily customizable. Pierre HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated
Re: [Alsa-user] First post
If you're really into going it on your own. There's gentoo, and there's LFS aka linux from scratch. Both of which impose a lot of source compilation. The inherent problem with sources is that you run into maintenance issues. i.e. If you use the same install for a long enough time, it'll eventually become unusable due to remnants of old versions and not enough hours in a lifetime to figure out what/where those are and manually correct. Ultimately you'll be doing fresh installs long before your hardware's expiration date. Not that I don't do regular installs myself. But I swap out hard drives every two years to be pro-active against that type of failure. And I do a lot of media editing, so I probably abuse my drives more than most. A distro is just a good ideal. There's configuration files that you really can't generate by hand without a pretty hefty understanding of what you are doing. Distros have done all this legwork for you and provide you with a sane default configuration file where you just need to uncomment a line to enable something or comment it to disable it. Lots of sanity saving things in a distro that you'll be scouring sources to figure out on your own in LFS land. And probably installing a distro anyway to cp their config. There's a lot to learn. But really you don't need to learn that stuff. There's no bread and butter / money in it. Sure you'll have a greater understanding. And should some do or die worst case scenario happen you'll know how to resolve it, where most other folks wont know where to begin. But really most IT jobs these days are installing and uninstalling and configuration gigs. We don't need to write a word processor, as one (several actually) already exist. And some of them aren't too shabby. As far as build systems. The configure + make + make install is the OLD way. Not all sources use that one. There's scons, mercurial, and various *make incarnations. And of course distro specific ways that are compatible with their package manager(s). Plus the typical development role of 1001 ways to do one thing. Fortunately alsa is still a bit old school. Or unfortunately depending on your POV. - James -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
version of alsa (or remove). Plus that whole depmod thing. $ dpkg -l '*kernel*headers*' Which resolves to linux-kernel-headers in debian. Which is a psuedo package for: linux-libc-dev 2.6.26-26lenny3 and of course 2.6.26-26lenny3 resolves to linux-tree-2.6.26lenny3 so: # apt-get install linux-libc-dev linux-tree-2.6.26-26lenny3 (in debian 5.0 / lenny) If it's a custom one, just don't make clean after making the kernel. It should reside in /lib/modules/`uname -r`/build/ or something like that. BITD, this would just be a symlink to/from /usr/src/linux and was what early alsa assumed by default. Depending on what multimedia features you need. You might want --with-sequencer=yes and --with-oss=yes and a --driver=your card options on your alsa-driver compile. Without those =no might be assumed. And you might compile ALL drivers which could take a really long time. Less so these days, but BITD, the better part of a day it seemed. It really depends on what you want interacting with your sound card. Timidity and other synth like software requires the --with-sequencer=yes if your card doesn't have native midi abilities (most don't these days). And various pulse-audio and browsers and other things that just need --with-oss=yes or things might not work as expected, if at all. Little things that you'll find out one way or another as you learn your way around. HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Hi James, thanks for your help too. :) I'll provide replies in the same fashion given. A) I don't want to overwrite the Kubuntu installation files as I'm compiling this version of alsa for my own distro. I would prefer to use Kubuntu's pre-packaged software within itself. So since the compiled version of alsa will be going into /opt/staging/alsa, should I include --prefix=/opt/staging/alsa as the parameter to configure? B) I'll assume at this point, that no matter what version of the Linux kernel is being used, it's still required to install the alsa-driver package. That being said, I'm going to run into the same problem as A above since the version of Kubuntu I'm using to build the custom distro isn't using the same kernel version. So what configure option do I have to pass in order for alsa to see the source code of the custom distro's kernel version? C) So far, so good, but I'll keep that in mind. :) D) Thanks for the URL, but this is a project that I've wanted to do for the last 5-7 years and now I have the ability to do so. Not only that, but knowing details at this level of building an OS can also help with my job - so I get a two fold benefit. :) Otherwise, I'd definitely follow your advice! lol Thanks again for your help, I look forward to hearing back from you. Dave On 06/19/2011 04:36 PM, James Shatto wrote: A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only
Re: [Alsa-user] First post
On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... Great one less thing to compile! :) 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? Humm ! I don't really understand this method. In my opinion if you want to have a custom distro you first install a basic systme on a partition or in a directory. Once the basic system is installed (more or less the content of the lfs book) you simply chroot to this new system to install the rest of the stuff. Following this scheme there will be no problem. I did it many times ! It leads me to a more global question : you say you want to build a custom distro but do you have some kind of documentation to do that ? If you plan to do that on your own, it's a big deal ! Anyway I'll suggest you to have a look at the lfs book. It might be that the installation schedule suggested by the lfs team is not suitable for you but in my opinion it is better to check this point before reinventing the weel as we say in french ! Bests Pierre I guess the best way to describe what I'm trying to accomplish would be to look at it from a package maintainers perspective. They have to compile the source code into a staging directory so they can package the software. If they just ran the normal configure make make install, how would they know what files to include in the software package as they get spread through the FS? There has to be a staging directory that contains everything in isolation so that the package maintainer doesn't have to do so much overhead just to create a package, but when the package is installed, it works correctly (hence using DESTDIR and not --prefix). The problem I'm having, as stated, is that I think alsa is looking for header files or whatever under normal installation directories (e.g. /usr/... or /usr/local/...), but I need it to look under the staging directory (/opt/staging/alsa) since that's where the other matching compiled packages of alsa reside. Any thoughts to accomplish this? In other words, what are the compile parameters a package maintainer includes to compile alsa? Thanks, Dave -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track
Re: [Alsa-user] First post
Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/. /usr/share/doc/. (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Henderson dhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? This question is answered by the blfs book. First alsa-lib and after alsa-utils. 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? No ! I am running a 2.6.32 kernel and never installed alsa-driver. Anyway if the sound system is something very exotic it might be necessary ... Great one less thing to compile! :) 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package
Re: [Alsa-user] First post
I think your statement here i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? best sums it up. Without a staging directory to install to, you would have to parse the entire FS in order to find what the make install step did. By using a staging directory, you still run make install, it just installs everything in it's retained hierarchy within that staging directory. That's why I said /opt/staging/alsa/bin in Kubuntu (build OS) becomes /bin in the custom distro. That's what the DESTDIR parameter does, it allows you to retain whatever directory hierarchy to use, but during the make install phase, instead of using / as the root, it uses whatever you include (e.g. DESTDIR=/opt/staging/alsa) as the value pre-pended for root. Honestly, at this point, we've gotten way off topic. lol These are all issues for me to work out, but appreciate you guys efforts. :) Presently, I'm thinking that alsa-utils (as we've determined alsa-driver probably doesn't have to be installed) is failing to compile because it's looking under /... for the header files and not /opt/staging/alsa/... Is there a way to make the configure script look into that directory for the header files during the configure phase? Thanks again for everyone's continued efforts in getting this matter resolved. Dave On 06/20/2011 04:06 PM, James Shatto wrote: Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/. /usr/share/doc/. (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Hendersondhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro
Re: [Alsa-user] First post
This is part of the reason that I use --prefix=/usr because the /usr/includes/ are also affected by the --prefix option (i.e. /usr/local/includes / which is empty). And I've never really gotten into the changing $PATH part of things. But there's a whole slew of -I and -L options (with a different case / case sensitive) for gcc to bypass / customize a lot of that. A real PITB IMO. But just my opinion. i.e. Use what is already there, not re-invent it in your image. And yes a bit OT at this point. - James On 6/20/11, David Henderson dhender...@digital-pipe.com wrote: I think your statement here i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? best sums it up. Without a staging directory to install to, you would have to parse the entire FS in order to find what the make install step did. By using a staging directory, you still run make install, it just installs everything in it's retained hierarchy within that staging directory. That's why I said /opt/staging/alsa/bin in Kubuntu (build OS) becomes /bin in the custom distro. That's what the DESTDIR parameter does, it allows you to retain whatever directory hierarchy to use, but during the make install phase, instead of using / as the root, it uses whatever you include (e.g. DESTDIR=/opt/staging/alsa) as the value pre-pended for root. Honestly, at this point, we've gotten way off topic. lol These are all issues for me to work out, but appreciate you guys efforts. :) Presently, I'm thinking that alsa-utils (as we've determined alsa-driver probably doesn't have to be installed) is failing to compile because it's looking under /... for the header files and not /opt/staging/alsa/... Is there a way to make the configure script look into that directory for the header files during the configure phase? Thanks again for everyone's continued efforts in getting this matter resolved. Dave On 06/20/2011 04:06 PM, James Shatto wrote: Ummm. I'm not sure if I follow you. $ make will build the objects and stuff in the current path of your source tree. $ make install copies the executables to the system usable locations. /usr/bin/ /lib/modules/. /usr/share/doc/. (which is why you need to be root in a lot of cases to run make install, but not to run make) A package maintainer will likely use stuff like what's in debian/rules debian/binary and such to build a package manager package, instead of using make install to place the important components (results) where they need to be. A package manager package lets you keep track of what got installed and where and the package provides additional features useful for long term maintenance and/or large scale deployment. If you want to build a package (i.e. .deb) you'd use those tools for that to do that. Otherwise you have to at least mimic make install. Which is a bit futile IMO, given that you could just run make install. i.e. how exactly would you create your tarball? From a diff of an entire backup before and after make install? By doing everything done by make install manually? That's fine for relatively small things like alsa. But for X, KDE, ???, and other more bulky entities. You'd need a couple lifetimes of spare time to re-invent make install. And scons install and and ... and ... Also bear in mind that if you're building something on a system other than the one where it will be deployed. You will run into some version compatibility issues. Just a minor difference in the API between version 1.0.24 and 1.0.25 could make things unusable. And as previously mentioned, alsa comes with the 2.6 kernel, so you'll have an existing version already in place that you will need to deal with, one way or another. When there's multiple versions of things, at runtime things like to load in alphabetical order or ascii order at least. Which generally means the that OLDer version takes priority. So even if you install your newer version, it's probably going to be ignored unless you remove or replace the older version. The manual approach to dependency hell I guess, of sorts. Lots of little things that will keep you from succeeding. It's probably time better spent learning an existing package management system IMO. Than to create your own. Especially if you're on your own and not part of team. But it's almost all open source so if you can read the source, everything that you need to know is there in one form or another. - James On 6/20/11, David Hendersondhender...@digital-pipe.com wrote: On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: Hi, From: David Hendersondhender...@digital-pipe.com Subject: Re: [Alsa-user] First post Date: Sun, 19 Jun 2011 15:28:48 -0400 Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously
[Alsa-user] First post
Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version = 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Henderson dhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version = 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com HTH, - James On 6/19/11, David Henderson dhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] First post
Hi James, thanks for your help too. :) I'll provide replies in the same fashion given. A) I don't want to overwrite the Kubuntu installation files as I'm compiling this version of alsa for my own distro. I would prefer to use Kubuntu's pre-packaged software within itself. So since the compiled version of alsa will be going into /opt/staging/alsa, should I include --prefix=/opt/staging/alsa as the parameter to configure? B) I'll assume at this point, that no matter what version of the Linux kernel is being used, it's still required to install the alsa-driver package. That being said, I'm going to run into the same problem as A above since the version of Kubuntu I'm using to build the custom distro isn't using the same kernel version. So what configure option do I have to pass in order for alsa to see the source code of the custom distro's kernel version? C) So far, so good, but I'll keep that in mind. :) D) Thanks for the URL, but this is a project that I've wanted to do for the last 5-7 years and now I have the ability to do so. Not only that, but knowing details at this level of building an OS can also help with my job - so I get a two fold benefit. :) Otherwise, I'd definitely follow your advice! lol Thanks again for your help, I look forward to hearing back from you. Dave On 06/19/2011 04:36 PM, James Shatto wrote: A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have a nice base for a command line OS, but want to expand into the multimedia aspect. Alsa was my first (only?) choice for the audio portion, but I'm running into problems. The alsa site is somewhat overwhelming to newbies and is easy to get lost. I have a few questions below from which I hope I can find help. All contributions are greatly appreciated. :) Thanks, Dave 1) Currently I have downloaded alsa-driver, alsa-lib, and alsa-utils packages. Is there an order in which these packages need to be compiled and installed? 2) I'm currently running the relatively new Linux kernel 2.6.33 so do I need the alsa-driver package? 3) I've been able to successfully compile the alsa-lib package and install it in the custom distro. When I try to compile the alsa-utils package, I constantly get the error: checking for libasound headers version= 1.0.16... not present. configure: error: Sufficiently new version of libasound not found. I'm actually using an existing Kubuntu installation to build the packages for my custom distro. As a result, after I compiled the newer alsa-lib, I didn't install the package into the Kubuntu OS, but rather a staging directory (/opt/staging/alsa). I'm sure the reason this is failing is because it's probably looking for /usr/lib/... or some other default location. How do I tell the configure script for the alsa-utils to look in the staging directory for the header files it needs? -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility
Re: [Alsa-user] First post
--prefix is a ./configure option. If you're going to apply the new alsa to an existing distro kernel and not a custom from source one. You'll likely need to install the kernel-headers package for that kernel and distro. And may need to manually move the old version of alsa (or remove). Plus that whole depmod thing. $ dpkg -l '*kernel*headers*' Which resolves to linux-kernel-headers in debian. Which is a psuedo package for: linux-libc-dev 2.6.26-26lenny3 and of course 2.6.26-26lenny3 resolves to linux-tree-2.6.26lenny3 so: # apt-get install linux-libc-dev linux-tree-2.6.26-26lenny3 (in debian 5.0 / lenny) If it's a custom one, just don't make clean after making the kernel. It should reside in /lib/modules/`uname -r`/build/ or something like that. BITD, this would just be a symlink to/from /usr/src/linux and was what early alsa assumed by default. Depending on what multimedia features you need. You might want --with-sequencer=yes and --with-oss=yes and a --driver=your card options on your alsa-driver compile. Without those =no might be assumed. And you might compile ALL drivers which could take a really long time. Less so these days, but BITD, the better part of a day it seemed. It really depends on what you want interacting with your sound card. Timidity and other synth like software requires the --with-sequencer=yes if your card doesn't have native midi abilities (most don't these days). And various pulse-audio and browsers and other things that just need --with-oss=yes or things might not work as expected, if at all. Little things that you'll find out one way or another as you learn your way around. HTH, - James On 6/19/11, David Henderson dhender...@digital-pipe.com wrote: Hi James, thanks for your help too. :) I'll provide replies in the same fashion given. A) I don't want to overwrite the Kubuntu installation files as I'm compiling this version of alsa for my own distro. I would prefer to use Kubuntu's pre-packaged software within itself. So since the compiled version of alsa will be going into /opt/staging/alsa, should I include --prefix=/opt/staging/alsa as the parameter to configure? B) I'll assume at this point, that no matter what version of the Linux kernel is being used, it's still required to install the alsa-driver package. That being said, I'm going to run into the same problem as A above since the version of Kubuntu I'm using to build the custom distro isn't using the same kernel version. So what configure option do I have to pass in order for alsa to see the source code of the custom distro's kernel version? C) So far, so good, but I'll keep that in mind. :) D) Thanks for the URL, but this is a project that I've wanted to do for the last 5-7 years and now I have the ability to do so. Not only that, but knowing details at this level of building an OS can also help with my job - so I get a two fold benefit. :) Otherwise, I'd definitely follow your advice! lol Thanks again for your help, I look forward to hearing back from you. Dave On 06/19/2011 04:36 PM, James Shatto wrote: A) If you want to overwrite your existing distro's versions, you probably want the --prefix=/usr option on your ./configure commands. If not, be sure to change your $PATH to look at /usr/local FIRST. B) Compile alsa-lib first, alsa-driver second. Most compile options only need --prefix=/usr if you want to override the default of /usr/local. But alsa-driver requires extra parms depending on what you want. Some packages are only tool sets, so make -f Makefile? And use them from where you made them, or copy/move them to more common $PATH's. C) You might have versioning conflicts depending on what you're trying to mix and match. libc and other things might not work well together unless you're running the latest and greatest of every component. And even that is problematic some of the time. D) unless you have a lot of time to waste, or just need the learning, I'd recommend going with existing distros. There's enough of them that one might suit your current needs. www.distrowatch.com HTH, - James On 6/19/11, David Hendersondhender...@digital-pipe.com wrote: Thanks for the reply Pierre. I checked into the blfs book, but it merely says these five chapters will cover alsa and then gives you a basic type configure make. This is obviously not going to answer the questions below. :) Any other thoughts? Dave On 06/19/2011 11:22 PM, Pierre Lorenzon wrote: Hi, It looks like to me such questions are well answered in the blfs book. I personnaly think that the latter is a very good tool to build his own custom distro. Bests Pierre From: David Hendersondhender...@digital-pipe.com Subject: [Alsa-user] First post Date: Sun, 19 Jun 2011 14:41:08 -0400 Hi everyone! I'm currently expanding my knowledge of GNU/Linux to include building packages from scratch towards an overall goal of a custom distro. So far, I have
