This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
autoconf and porting
- From: Justin Wilson <jrwilson at go dot wustl dot edu>
- To: <libc-help at sourceware dot org>
- Date: Tue, 17 Jan 2012 18:18:09 -0600
- Subject: autoconf and porting
My question seems to straddle a number of lists so I'll start it here
and move it later.
I'm working on a new operating system and I'm to the point that I need
a C library for user space programs.
I compiled a cross compiler for the new operating system and started
the process of porting glibc.
My main barrier so far has been the use of autoconf to configure glibc.
Let me explain with an example.
The glibc configure.in script contains a fragment that expands to
something like this
...
#include <stdarg.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
...
FILE * (*rcsopen) (struct buf *, struct stat *, int);
...
when checking for C89 compliance.
The problem is that my cross-compiling environment does not have
headers like <stdio.h>, <sys/types.h>, etc. so a variety of tests fail.
glibc uses autoconf for configuration.
autoconf assumes a Unix-like environment.
Consequently, one cannot compile glibc for an environment that doesn't
resemble UNIX.
Am I correct in my belief that the problem lies strictly with autoconf?
In the short-term, does anyone have a perspective on what dragons are
lurking if I try to compile glibc without autoconf?
Justin Wilson