Re: [Texmacs-dev] nogencc-0.10

[David Allouche]

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.

> > 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.

> > 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.

> > 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.

> > 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.

> > 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).

> > 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.

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.

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

Ok.
-- 

                                  -- David --