This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I see.The preconfigure file you have is not appropriate. The purpose of the preconfigure file is really only if it's needed to set $machine et al, which is only the case if config.sub doesn't always output the right one string (and you don't have machine variant subdirs you want to use). Your port does not need a preconfigure script at all.
Your sysdeps/m32r/preconfigure file just does some generic check. ItThanks, I try again.
should be done in the later phase on figure, i.e. in a "configure" file not
a "preconfigure" file. Furthermore, you provided a preconfigure without a
preconfigure.in, and hard-coded autoconf internals in it. What you should
really have is a sysdeps/m32r/configure.in that uses AC_DEFINE, and a
sysdeps/m32r/configure generated from that. Take a look at the scripts
I've just added to ports/sysdeps/cris as the model.
Yes. I will do that.The natural way to distribute an individual add-on port is not as a patch, but as an add-on tar file. Make a tar file including your new sysdeps directories, ChangeLog.m32r, and the few top-level script files from the ports directory (configure, configure.in, Makefile, Makeconfig), and a Banner file if you like. This is something that your users can drop into glibc just like the ports add-on.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |