Re: [Texmacs-dev] nogencc-0.10

[Joris van der Hoeven]

On Tue, 14 May 2002, David Allouche wrote:

> On Tuesday 14 May 2002 10:48, Joris van der Hoeven wrote:
> > > Added test for "-fno-rtti -fno-exceptions" in configure script.
> > > Inspired from a test in ltconfig (in GNU libtools).
> >
> > What about implicit-templates? Did you test the difference
> > in code size and execution speed in the official distribution?
> 
> Since I was sure of the result I did not test it, but you insist on it...
> 
> normal build, MIXED_TEXMACS, stripped
> -rwxr-xr-x    1 david    david     3665256 May 14 13:15 texmacs.bin*
> 
> -fno-implicit-templates, MIXED_TEXMACS, stripped
> -rwxr-xr-x    1 david    david     3665256 May 14 14:08 texmacs.bin*
> 
> diff shows that the binaries are identical.
> 
> That is no surprise since the official TeXmas distribution do not use 
> templates.
> 
> Anyway implicit templates only affect the compilation, and in no way the 
> quality of the generated code.

Thanks for pointing this out; I put this options because I noticed
them in the Polish linux distribution. But I now understand that
the option is useless.

> > > Removed MAKE definition in main Makefile to support GNU Make
> > > installed as gmake.
> >
> > ?
> 
> From the GNU make documentation
> 
>        Recursive `make' commands should always use the variable
>     `MAKE', not the explicit command name `make', as shown here:
> 
>          subsystem:
>                  cd subdir && $(MAKE)
> 
>        The value of this variable is the file name with which
>     `make' was invoked. If this file name was `/bin/make', then
>     the command executed is `cd subdir && /bin/make'. If you use a
>     special version of `make' to run the top-level makefile, the
>     same special version will be executed for recursive
>     invocations.
> 
> So the definition of the MAKE variable in the base Makefile was not only 
> useless, it was also problematic. Since my new makefiles in the src 
> directory use features specific to GNU make, we must be able to use
> GNU make recursively even on UNIX systems where it is called gmake.

OK; I assume that the environment variable MAKE is automatically set
to make if we do not use gmake?

> > > Removed word-alignement compiler options. They provided only the
> > > default values on Intel and Sparc, and caused error on Solaris
> > > (gcc version 2.95.2 19991024).
> >
> > This should depend on the architecture;
> > the options should be included on Intel and Sparc.
> 
> On the Sparc Solaris testing machine at SourceForge, it causes an error. 
> Apparently, the version of gcc installed there wants the actual 
> alignement value. But later gcc versions (at least the one installed 
> here) use the provided value as an exponent of 2.
> 
> The consequence on that SourceForge machine is that the compiler cause an 
> error because the alignment value is smaller than the word size.
> 
> Anyway my gcc manual reads:
> 
> For i386:
> 
>     `-malign-loops=NUM'
>          Align loops to a 2 raised to a NUM byte boundary. If
>          `-malign-loops' is not specified, the default is 2 unless
>          gas 2.8 (or later) is being used in which case the
>          default is to align the loop on a 16 byte boundary if it
>          is less than 8 bytes away.
> 
>     `-malign-jumps=NUM'
>          Align instructions that are only jumped to to a 2 raised
>          to a NUM byte boundary. If `-malign-jumps' is not
>          specified, the default is 2 if optimizing for a 386, and
>          4 if optimizing for a 486 unless gas 2.8 (or later) is
>          being used in which case the default is to align the
>          instruction on a 16 byte boundary if it is less than 8
>          bytes away.
> 
>     `-malign-functions=NUM'
>        Align the start of functions to a 2 raised to NUM byte
>          boundary. If `-malign-functions' is not specified, the
>          default is 2 if optimizing for a 386, and 4 if optimizing
>          for a 486.
> 
> For Sparc:
> 
>     `-malign-loops=NUM'
>          Align loops to a 2 raised to a NUM byte boundary. If
>          `-malign-loops' is not specified, the default is 2.
> 
>     `-malign-jumps=NUM'
>          Align instructions that are only jumped to to a 2 raised
>          to a NUM byte boundary. If `-malign-jumps' is not
>          specified, the default is 2.
> 
>     `-malign-functions=NUM'
>          Align the start of functions to a 2 raised to NUM byte
>          boundary. If `-malign-functions' is not specified, the
>          default is 2 if compiling for 32 bit sparc, and 5 if
>          compiling for 64 bit sparc.
> 
> So these options just force what is generally the defaut, and prevent the 
> use of more sensible settings in special cases.

Hmm, so why do many people explicitly specify them?
Again, other suggested me to use these flags...

> > > Removed --no-rtti option, because it caused a link error with
> > > gcc-2.95.2.
> >
> > Please put in a condition for this; I would like to keep this option
> > whenever possible. By the way, I do not have this problem with
> > gcc-2.95.2.
> 
> I had this problem on all the machines running gcc-2.95.2 at SourceForge. 
> That is the Sparc Solaris machine and the PPC/RS6000 and Alpha Debian 
> machines. At link time I had "undefined symbol xxxxx_typeinfo" errors, or 
> something similar.
> 
> I am not willing to work out a configure test to detect this problem 
> because it is likely to appear only in complex cases. Moreover, since you 
> tell me that you cannot reproduce the problem with your version of the 
> compiler, we cannot simply test the version of gencc.

It should be easy to build a configure test for this problem:
just check whether compilation of a virtually empty file works
with this option.

Again, you might compare the binaries produce with and
without this option; if they are identical, then I will
stop bothering you with this.

> > > Added .PHONY targets to accomodate for Cygwin's case insensitive
> > > filesystem.
> >
> > Is that necessary? We did not need that on Cygwin.
> 
> That not only necessary, that is also good practice.
> 
> If you check the message about compiling for Cygwin on texmacs-users, you 
> will see that it is necessary to make MISC by hand. The problem is that 
> Cygwin's file-system is case unsensitive, so when you do $(MAKE) MISC it 
> does nothing since a "misc" directory already exists and the MISC target 
> has no prerequisite.
> 
> In your makefile you use a lot of phony targets (see GNU make 
> documentation). Not declaring them as such is very bad practice.

Hmm, I never understood the use of .PHONY,
but I will take a look when I have time.
I also remember that there was a way to
make Cygwin case sensitive:

        export CYGWIN=check_case:strict

> > > Assorted minor fixes to makefiles.
> > >
> > > Tested compilation on:
> > > Debian 3.0 on Intel               gcc version 2.95.4 20011002 (Debian 
> > > prerelease)
> > > RH-7.3 on Intel                   gcc version 2.96 20000731
> > > RH-7.1 on Alpha                   gcc version 2.96 20000731
> > > Solaris8 on Sparc R220            gcc version 2.95.2 19991024 (release)
> > > Debian-2.2 on PPC RS/6000 gcc version 2.95.2 20000220 (Debian
> > > GNU/Linux) Debian-2.2 on Alpha            gcc version 2.95.2 20000220 
> > > (Debian
> > > GNU/Linux) FreeBSD 4.5 on Intel           gcc version 2.95.3 20010315
> > > (release)
> > > Cygwin on Windows98               gcc version 2.95.3-5 (cygwin special)
> >
> > Great. Did you try to execute the binaries too?
> > This is important, because the application sometimes segfaults.
> 
> I only tested on Cygwin. I have no way to test an X application on the 
> Compaq TestDrive's machines (first three) and on the SourceForge compile 
> farm's machines (all the rest but Cygwin).

OK, but you might still try to simply start it and wait
for the error message that you are not allowed to open the display.
Sometimes execution breaks already before that.

> > > Could not even compile mainline on MacOS X. However, there is a Fink
> > > package, so it is possible with a bit hacking.
> >
> > Strange, the official distribution has been reported to
> > compile & execute well.
> 
> Probably with some hacking of the makefiles, as I said.

Well, this is what has been done in versions 1.0.0.2 until 1.0.0.4,
so you may check the diffs.

> I tried to compile on a SourceForge's Darwin machine, but it was unable 
> to find some system header which was present in /sw/include.
> FYI, /sw is the standard installation directory of Fink.

You may also contact Michel Costabel for help on Darwin specific issues:

        address@hidden

> > > Removed use of H convenience macro in hashmap.cc and hashmap_extra.cc
> > > because it confused Doxygen.
> >
> > Please postpone this change.
> 
> Ok.

Thanks.