Re: build trouble on MacOS 10.5 [changeset]

[Ben Abbott]

On Dec 23, 2009, at 10:03 PM, John W. Eaton wrote:

> On 23-Dec-2009, Rob Mahurin wrote:
> 
> | On Tue, Dec 22, 2009 at 09:00:45PM -0800, Rik wrote:
> | > On the other hand, since this seems to be
> | > required only for MAC builds I would put comments to that effect
> | > everywhere you insert a config.h call.  
> | 
> | It seems to be a gnulib requirement.  According to 
> | http://www.gnu.org/software/gnulib/manual/gnulib.html, 
> | 
> |     In the usual case where Autoconf is creating a config.h file,
> |     you should include config.h first, before any other include
> |     file. That way, for example, if config.h defines ‘restrict’ to
> |     be the empty string on a pre-C99 host, or a macro like
> |     ‘_FILE_OFFSET_BITS’ that affects the layout of data
> |     structures, the definition is consistent for all include
> |     files. Also, on some platforms macros like ‘_FILE_OFFSET_BITS’
> |     and ‘_GNU_SOURCE’ may be ineffective, or may have only a
> |     limited effect, if defined after the first system header file
> |     is included.
> | 
> | So I think that, even though this problem showed up on OSX first,
> | similar weirdness will happen on other systems where the C library is
> | not quite glibc.
> | 
> | > I am reluctant to rewrite the lex rule for compilation in
> | > src/Makefile.am.  Currently we use configure and automake to work out
> | > the right command to call.  I checked the patch and it does produce the
> | > identical call to that which configure/automake worked out for my Linux
> | > system, but I'm not sure that can be guaranteed into the future.
> | > 
> | > If you do go ahead, I think this shell rule would be more portable than
> | > Perl:
> | >     mv $@ address@hidden
> | >     echo "#ifdef HAVE_CONFIG_H\n#include <config.h>\n#endif" > $@
> | >     cat address@hidden >> $@
> | >     rm -f @<-t
> | 
> | Well, it would have to be echo -e, which works with bash's builtin
> | echo but not with my /bin/echo.  
> | 
> | Perl is listed as a build requirement in the file HACKING,
> 
> It is, but I would like to limit its use as I would eventually like to
> try to eliminate it from the list of build requirements.  I guess I
> should probably state that in the HACKING file...
> 
> I found the following thread from the gnulib mailing list that
> describes the same problem we are having.
> 
>  http://old.nabble.com/getopt.h-broken-on-FreeBSD-td25956219.html
> 
> A reply in the thread suggests using the %top directive for flex.  I
> think that is a better solution, so I checked in the following change.
> 
>  http://hg.savannah.gnu.org/hgweb/octave/rev/7ad32bf759c3
> 
> Does this solve the problem with compiling lex.ll for you?
> 
> Since there are no special automake generated rules for gl2ps.c as
> there are for lex.ll, we can just treat it as though it is an include
> file (same as we currently do for files like mx-inlines.cc) and
> provide a wrapper as I suggested earlier.
> 
> jwe

Out of curiosity, I was poking around the makefile.am to see if it was clear 
what needed to be done there.

If a new file is added called gl2ps-wrapper.c which includes ...

        #ifdef HAVE_CONFIG_H
        #include <config.h>
        #endif
        #include <gl2ps.c>

... is it sufficient to replace gl2ps.c with gl2ps-wrapper.c in DIST_SRC ?

Ben