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
