Re: First post

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



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


[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