Re: nam-1.0a7

[Stefan Dresler <Stefan.Dresler@telematik.informatik.uni-karlsruhe.de>]

Dear Juana, Haobo, ns-users, 

> ns is working fine but I was unable to compile nam-1.0a7. It gave me the

> This is an old bug,

Yes ;-) We had the same problem with an older release, and now again
with the newest.


> which unfortunately still found its way into this
> release. :( The solution is described in 
> http://mash.cs.berkeley.edu/nam/nam-problems.html. 

This only seems to be a solution for an older nam version.
Two of the three alterations described cannot be applied
anymore because the lines do not match those described (at least in our
installation, which should be the newest 2.1b5, installed yesterday night).

<quote reformatted>
     Add this to the file xwd.c as line 92
     #define SIZEOF(x) sz_##x

     Comment out line 59 of the file config.h.
    /* typedef signed char int8_t; */

     Comment out line 45 in random.cc
     /* extern "C" int srandom(...); */
</quote>

The first patch works and should be the reason for the compile error,
as can be seen from the (correct) warning that SIZEOF has been redefined
once the patch is applied:

xwd.c:93: warning: `SIZEOF' redefined
/usr/include/X11/Xmd.h:92: warning: this is the location of the previous 
definition

Those lines in the file (again, in our installation) are:
/*
 * Definition of macro used to set constants for size of network structures;
 * machines with preprocessors that can't handle all of the sz_ symbols
 * can define this macro to be sizeof(x) if and only if their compiler doesn't
 * pad out structures (esp. the xTextElt structure which contains only two
 * one-byte fields).  Network structures should always define sz_symbols.
 *
 * The sz_ prefix is used instead of something more descriptive so that the
 * symbols are no more than 32 characters long (which causes problems for some
 * compilers and preprocessors).
 *
 * The extra indirection in the __STDC__ case is to get macro arguments to
 * expand correctly before the concatenation, rather than afterward.
 */
#if ((__STDC__ || defined(__cplusplus) || defined(c_plusplus)) && !defined(UNIXC
PP)) || defined(ANSICPP)
#define _SIZEOF(x) sz_##x
#define SIZEOF(x) _SIZEOF(x)
#else
#define SIZEOF(x) sz_/**/x
#endif /* if ANSI C compiler else not */


So the "real" reason (again, at least in our installation and with our
libraries, include files and compiler(s)) is the compiler's inability to
correctly process sz_/**/x (or alternatively sz_##x, which is supposed
to do the same): in includes a space instead of just throwing away
the comment and directly
concatenating the two parts of the string, sz_ and x, which can been seen
by looking at the precompiler output.

So I guess it is possible to directly add the sz_ prefix in all (three)
lines in xwd.c where SIZEOF is used, but I did not test this.

If I only use the first patch hint (add a line with #define), the files
compile and link nicely (haven't tested it yet, though), with the warning
mentioned above. So this
is what I recommend until someone convinces me of something else :-)

What we did originally was to change xwd.c to include some numbers
(but do not ask my now where we got those from), and this worked, too:

diff nam-1/xwd.c nam-1.orig/xwd.c
279c279
<       header_size = SIZEOF(XWDheader) + win_name_size;
---
>       header_size = 100 + win_name_size;
328c328
<       if (fwrite((char *)&header, SIZEOF(XWDheader), 1, out) != 1 ||
---
>       if (fwrite((char *)&header, 100, 1, out) != 1 ||
345c345
<               if (fwrite((char *) &xwdcolor, SIZEOF(XWDColor), 1, out) != 1) {
---
>               if (fwrite((char *) &xwdcolor, 12, 1, out) != 1) {


Hope this helps, if anything was unclear at all.

Yours,
	Stefan