gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] GCC 4.4 and strict aliasing


From: Jerry James
Subject: Re: [Gcl-devel] GCC 4.4 and strict aliasing
Date: Mon, 23 Feb 2009 13:30:55 -0700

On Mon, Feb 23, 2009 at 1:10 PM, Camm Maguire <address@hidden> 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/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]