Re: First post

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



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


[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