Re: First post

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Free Dating Site]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux