Ok I'll try the alsa-devel mailing list. Thanks again for all your help James (and everyone else who contributed)! :) Dave On 06/21/2011 08:56 AM, James Shatto wrote: > Circles it is. > > --prefix tells your configure where to expect things AND where to put > them when it's done. If you're going to go outside the norm and not > use /usr/ or /usr/local/ you should check ./configure --help for > telling it where to look for includes, libs, and other things that it > will compile against. Otherwise it wont find basic stuff and fail to > compile. i.e. It needs the kernel headers, it needs other standard > includes. It being alsa. i.e. --includedir, --libdir, and a whole > slew of OTHER configure options. It's far easier just to go with > defaults IMO. > > And we're OT for this list. You might check the alsa-devel mailing > list for guidance. Although I'm not on that list. alsa-project.org > should have info on that one. > > - James > > > On 6/21/11, David Henderson<dhenderson@xxxxxxxxxxxxxxxx> wrote: >> Hi James, if I use "configure --prefix=/opt/staging/alsa" then I'll have >> to create a directory on the custom distro that corrsponds to >> /opt/staging/alsa and store the alsa software in that directory (e.g. >> /opt/staging/alsa/bin, /opt/staging/alsa/lib, /opt/staging/alsa/var, etc >> instead of /bin, /lib, /var, etc). This is not what I'm looking for, >> but rather how do I get the "configure" script to simply look in >> /opt/staging/alsa for the directory hierarchy and header files during >> the compile process? Unless I'm completely misunderstanding what you're >> saying, it appears as though we're going around in circles. :) >> >> Dave >> >> >> On 06/20/2011 08:45 PM, James Shatto wrote: >>> 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<dhenderson@xxxxxxxxxxxxxxxx> 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 Henderson<dhenderson@xxxxxxxxxxxxxxxx> wrote: >>>>>> On 06/20/2011 11:52 AM, Pierre Lorenzon wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: David Henderson<dhenderson@xxxxxxxxxxxxxxxx> >>>>>>> Subject: Re: 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 Henderson<dhenderson@xxxxxxxxxxxxxxxx> >>>>>>>>> Subject: 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 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@xxxxxxxxxxxxxxxxxxxxx >>>>>> 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@xxxxxxxxxxxxxxxxxxxxx >>>>> 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@xxxxxxxxxxxxxxxxxxxxx >>>> 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@xxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
