glibc configparms file unnecessary
sostrovsky at snip.net
Mon Nov 27 18:37:51 PST 2000
Erika Pacholleck wrote:
> Besides that (I also use it with a lot of definitions) I understood the
> reason for the configparms to be there like this:
> This is the special for the glibc stuff. And if you have other add ons
> (ncurses for example can be add on to glibc) which need a different
> definition this will be handled be the configure script.
> Example: glibc man pages to /usr/man/glibc and ncusres one /usr/man1
> The glibc man pages are set in configparms and ncurses in configure.
I looked into glibc make- and configuration scripts and found following:
Short answer - yes you can, but this would mean that you configure one set
parameters for glibc alone, and another set for anything else ( linuxthreads
Here is how it works ( who are not curious, sorry about that ):
glibc-2.2/configure generates from the tiny glibc-2.2/Makefile.in
such as small glibc-build/Makefile.
This glibc-build/Makefile includes the glibc-2.2/Makefile,
which is the real top-level makefile for building glibc.
It is not a result of the regular macro-expantion Makefile.in->Makefile
performed by autoconfig-generated ./configure. It is not meant to be altered.
Instead, it includes the glibc-2.2/Makeconfig.
In turn, glibc-2.2/Makeconfig includes
glibc-build/config.make created when ./configure run.
It holds all the parameters that would be candidates for
macro-expantion in the regular scenario.
Yes, all these prefix=/usr, etc.
glibc-build/configparams is yours, if you cared to create it.
Three important things:
a) As far as I understood the script, it is not a crime not to have
b) If exists, it is included after glibc-build/config.make, thus takes
precedence over parameters
set in ./configure or defaults.
c) slibdir=/lib and sysconfdir=/etc are default values set in
so having them set again to very same in glibc-build/configparms does
Do not get me wrong - if people have had problems when glibc-build/configparms
doesn't exist, that means the problem is deeper than I see.
For add-on packages all the command line _after_ the word 'configure' is
passed to add-on's ./configure,
which is run for each add-on individually.
So, unless your add-on package is an "add-on-compatible" and reads config.make
from top-level glibc build directory ( Yeah, I knew what you think before you
have read );
it will be configured with not-configparms-altered parameters.
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the lfs-dev