Re: configure

[Bob Proulx]

Leon Torres Angeles wrote:
> I recently got installed the TurboLinux server 8
> I need to install a diferent DHCP client other then dhclient wich seems 
> cant complete the connection with the ISP

Hmm...  DHCP clients are so standard these days.  Frankly I suspect
that you have another issue such as a network connection problem or
some other such problem.  I am not convinced that if you install a
different dhcp client that it will perform better than any other
client.

> I was trying to install the dhcpcd, but it at the ./configure comand it 
> refused to continue asking for the
> CPU-VENDOR-SYSTEM option to be able continue

Sounds like a config.guess problem.  The config.guess script is an
optional part of the configuration system which tries to guess what
type of system you have.  If it can't then you would need to supply
one to it.  But I can't imagine why it would need this for a dhcp
client.  But if it is then it needs something like the following.
This is the output of config.guess on my GNU/Linux system.  (Of course
I am actually using an Athlon so the particular cpu is not of
importance here, it is the architecture that matters.)

  i686-pc-linux-gnu

> so reading here and there and running a few commands it seems I'm missing 
> the "autoconf"
> command so I already installed it, the m4 dependency was already there.

No.  The autoconf command is the program that created the configure
script in the first place.  If you have the configure script then you
don't need to create it and would not need autoconf.  Autoconf is
something that a developer working on modifications to the package
would need to recreate a new configure script.  But you as a
downstream user should not need autoconf.  You should be able to use
the configure script to generate your Makefiles.  But not all authors
are as effective at portability as others and sometimes there are
problems.  But that is the plan just the same.

> so I tryed again to run the ./configure command for the dhcpcd but still 
> the same result, no go.

It makes sense that the results you are seeing would be repeatable.

> I have little experience with linux, so I'm clearly missing some steps or 
> extra and basic options
> should I best be giving the arguments to the dhcpcd configure commmand and 
> how/where do I find them so that I may have already my linux-internet 
> connection

So now I am pretty much at the end of my knowledge.  I don't use
dhcpcd myself and don't know anything about it.  I googled around and
found several references to it.  It sounds like a fine tool.  I went
so far as to download dhcpcd-1.3.22-pl4 and it configured fine for me
and compiled with no errors on my Debian GNU/Linux system.  I am
guessing it should compile fine on your TurboLinux based system too.

Try running configure this way:

  ./configure --build=i686-pc-linux-gnu

Gratuitous editorial remarks follow: I just peeked into the
configure.in of that package and it uses the following.  I compacted
this to save some space in the email.

  dnl Detect the canonical host and target build environment
  AC_CANONICAL_HOST
  dnl Determining the compilation flags
  case $host_os in
          linux*) CFLAGS="$CFLAGS -O2 -fomit-frame-pointer -Wall $ADDS" ;;
  esac
  case $host_cpu in
          i486)   CFLAGS="$CFLAGS -march=i486" ;;
          i586)   CFLAGS="$CFLAGS -march=i586" ;;
          i686)   CFLAGS="$CFLAGS -march=i686" ;;
  esac
  LDFLAGS="-s -O2"

Blech!  Why does a dhcp client need to be so optimized?  It is not as
if these optimizations would actually be visible or useful to a user.
Best to avoid all of that.  If the user wants to tune it further then
they can provide the appropriate flags through CFLAGS.  Which comes to
the second point that LDFLAGS and CFLAGS should not be set like this
since it prevents the user from being able to control them.  And what
if the user is using a different compiler on linux?  I am not an
autoconf maintainer but these look like good examples of bad things
which should be avoided.

Bob