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
