On Mon, Feb 23, 2009 at 1:10 PM, Camm Maguire <c...@maguirefamily.org>wrote:
> Greetings! > > OK, a minimal bfd fix is in 2.6.8pre -- thanks Jerry! I'd really > prefer to keep 2.6.8pre changes to very important bug fix minimal mods > only, given the lack of resources we have to maintain two branches. > > I've followed Jerry's advise with a much more substantial configure.in > cleanup for cvs head, which should go in shortly. It is still not > complete. configure.in is too complicated, and the macro > interdependencies are difficult. I was wondering whether this would > be better done with a series of .m4 files to use with aclocal, but am > not really familiar with the tool, and need to carefully judge the > time required. At least acconfig.h can go (away) with the next > commit. I'm not really sure if configure.ac is a more modern name, or > whether this implies any syntax changes. Finally, the makefiles are > very fragile and really should go through automake, but this has ever > seemed a low priority. The configure.in to configure.ac name change is only to signal that you are using a newer autoconf. It does not imply any changes to the contents of the file itself. I've had mixed results with automake. My experience has been that automake helps me whip out simple Makefiles very quickly, and confuses the heck out of me when I need to do something complex. YMMV. > Other Jerry patches which appear to fall into the 'critical breakage' > category are: > > unrandomize -- which gcc cannot #include inside a function? I've used > this syntax forever. I hit this with Fedora 9, but only with -O2 or -O3. With -O0 or -O1, it worked fine. It appears to be caused by some recent glibc work. They've turned some former functions into inline functions or macros, so they can add some error-checking. In at least a few cases, the error-checking is only triggered by -O2 or higher, which is why -O1 works. When I complained about this, I was told that #include inside a function is not legal C, complete with a quote from the ANSI C spec. getcwd > selinux ? Most of the selinux patch is needed only for those building GCL on an SELinux-enabled host. However, those trying to run GCL on an SELinux-enabled machine will need to have the policy installed and the proper labeling in place on the image files. I have only ever used SELinux on Fedora, and don't currently have access to any other Linux distributions, so I'm not at all sure how to write a general guide to using GCL with SELinux. I can easily give the Fedora recipe. Is there anybody who can help me figure out how that recipe needs to be altered for other Linux distributions? elisp > The bfd and unrandomize patches include changes to configure.in. I cannot produce a working configure script with the autoconf I have available to me, which is the reason for the infrastructure patch. You'll probably have to change those patches somewhat to work with an older autoconf. Regards, -- Jerry James http://loganjerry.googlepages.com/
_______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
