Re: [aspell-devel] patch to fix for g++ -O3

[David Fang]

> Trying it again:
> tar -xzf ../aspell-0.60.5.tar.gz
> cd aspell-0.60.5/
> patch -p1 < ../aspell-0.60.5.patch
> autoreconf
> mkdir build
> cd build
> ../configure CFLAGS="-g -O3" CXXFLAGS="-g -O3" -C
>
> One line had a warning:
> configure: WARNING: Aspell will not be able to Display UTF-8 characters
> correctly.

Hi,
        I'm going to claim that none of my revisions directly caused that
warning, however autoreconf-ing some maintainer files might introduce some
differences.  I leave it to the maintainers to do the regeneration.

> Several output lines had g++ but there was no output containing:
> if g++ -DHAVE_CONFIG_H -I. -I../aspell-0.60.5 -I./gen  -Igen

The snippets below comtain "-Igen", so it looks correct to me.

> (make failed, therefore no "make check" done), here's the last lines:
> ------------------
>
> g++ -DHAVE_CONFIG_H -I. -I.. -I./gen -Igen -I../common -I../interfaces/cc/ 
> -I../modules/speller/default/ -DLOCALEDIR=/usr/local/share/locale -g -O3 
> -fno-exceptions -MT
> common/string_list.lo -MD -MP -MF
> common/.deps/string_list.Tpo -c ../common/string_list.cpp  -fPIC -DPIC -o
> common/.libs/string_list.o
> cd gen;
> perl ../../gen/mk-dirs_h.pl /usr/local /usr/local/lib/aspell-0.60 
> /usr/local/lib/aspell-0.60  /usr/local/etc
> >  dirs.h
> depbase=`echo common/config.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \
>         if /bin/sh ./libtool --tag=CXX --mode=compile
> g++ -DHAVE_CONFIG_H -I. -I.. -I./gen  -Igen -I../common -I../interfaces/cc/ 
> -I../modules/speller/default/ -DLOCALEDIR="/usr/local/share/locale"   -g -O3 
> -fno-exceptions -MT
> common/config.lo -MD -MP -MF "$depbase.Tpo" -c -o common/config.lo
> common/config.cpp; \
>         then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo";
> exit 1; fi
>
> g++ -DHAVE_CONFIG_H -I. -I.. -I./gen -Igen -I../common -I../interfaces/cc/ 
> -I../modules/speller/default/ -DLOCALEDIR=/usr/local/share/locale -g -O3 
> -fno-exceptions -MT
> common/config.lo -MD -MP -MF common/.deps/config.Tpo -c
> common/config.cpp  -fPIC -DPIC -o common/.libs/config.o
> g++: common/config.cpp: No such file or directory
> g++: no input files
> make[1]: *** [common/config.lo] Error 1
> make[1]: Leaving directory `/home/ze/temp/j/aspell-0.60.5/build'
> make: *** [all-recursive] Error 1
> ------------------

Now THIS baffles me.  It tried to build
        common/config.lo from common/config.cpp
whereas it should've built
        common/config.lo from $(srcdir)/common/config.cpp.
There's nothing in my revisions that touched common/config.cpp, I can
only conclude that it disappeared from your source directory.  (HUH!?)
Can you confirm that common/config.cpp exists in the original un-packing,
and still exists after patching and autoreconf-ing?  If it doesn't, then I
have no clue what went wrong.

> ls -l
> -rw-r--r-- 1 digital digital  11330 Jan  5 19:26 Makefile.am
> -rw-r--r-- 1 digital digital  79425 Jan  5 19:27 Makefile.in
>
> timestamp okay, plus doing a "diff" between original and updated version of
> Makefile.in shows substantial changes including the change you mentioned
> approximately around line 1880.
>
> > After Makefile.in is regenerated "config.status --recheck" should
> > automatically run when you try to make again.  (Or start from scratch.)
>
> Yes, it started from scratch.
> There was a "configure: creating ./config.status"
> ....followed by many lines recreated
> There is a "config.status" in the "build" directory.

Ok, that's to be expected.

> > Do the developers have a preferred way of regenerating files?  I noticed a
> > maintainer/ directory with scripts like 'autogen'.  (Wasn't mentioned in
> > the texinfo documentation.)
>
> Kevin is the developer, people like us go around annoying him since we don't
> know the tools ;-)   however, a normal user like me shouldn't really need to
> go into the maintainer directory since things should usually work under the
> magic commands of (normally):
> configure
> make
> make install

I hope we're not irritating him too much with this thread!

> > I only jumped into this today with a quick
> > fix, so pardon me I'm not familiar with others' habits and conventions.
>
> Not a problem. Your quick fix worked for you on a mac, but it seems not to
> work for me on a PC under this particular distribution. If you look at the
> bug list on sourceforge several bugs may possibly be fixed by what may
> sometimes seem like very "minor" fixes, but the main thing is to not break
> things for other users. For example, your minor fix could possibly open the
> door to fixing stuff like this:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1021597&group_id=245&atid=100245
> and maybe even this as well:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1242556&group_id=245&atid=100245
> and the configure options you mention could possibly open another door to
> trying stuff like "configure --other cpu" therefore opening up the
> possibility of seeing things like these without that particular CPU:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1504561&group_id=245&atid=100245
> http://sourceforge.net/tracker/index.php?func=detail&aid=1498387&group_id=245&atid=100245

Arg, I still see no reasons why my Makefile.am revisions should affect
building on one platform vs. another.  (Sure, the other piece of the patch
addressed a compiler issue.)  If I have caused any regression with this
patch, I'd like to know.  I might take a peek at those issues if they're
related and I feel I can help.

To other developers: Some of these packaging/path issues would be easily
tested if aspell were distcheck-able.  I'm attempting to "make distcheck"
right now, but 'distdir' fails because EXTRA_DIST contains patterns like
"*.h", which are not properly recognized by GNU make, nor expanded by
automake.  The first thing I'll try is to expand those lists manually in
EXTRA_DIST.



David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)