[Dvipng] dvipng and mmap preprocessor woes

[Karl Berry]

Hi Jan,

Vladimir discovered that dvipng/misc.c did not compile on AIX, where
mmap is a macro. This interferes with its usage as a structure member
name in dvipng's struct filemmap. (And this is allowed by C/POSIX
standards as far as I know -- my understanding is that basically any
"function" name can be a macro, as long as the result is addressable.)

Vladimir found a workaround (see patch and all the details below), but I
think the cleanest solution would be to simply rename the member field.
If you'd accept that, perhaps Vladimir or I could send you a patch for
that. (Vladimir: meanwhile, I installed your change below.)

By the way, do you have any plans to make another dvipng release? I'm
sorry for not writing earlier; I'd like to get the TeX Live tree to the
other builders as soon as possible.

Thanks,
Karl


Date: Sun, 27 Apr 2008 21:11:56 -0700
From: Vladimir Volovich <***@vsu.ru>
To: ***@freefriends.org (Karl Berry)

[...] what is happening is that texk/dvipng/misc.c #includes "dvipng.h"
which defines struct filemmap containing the field called "mmap".

then, misc.c includes <sys/mman.h>, which has "#define mmap mmap64",
so subsequent occurences of "mmap" get correctly translated to "mmap64".

but since "dvipng.h" was included prior to <sys/mman.h>, the "mmap"
field in "struct filemmap" was not affected by the "#define mmap
mmap64", which leads to inconsistency with later code which accesses the
"mmap" field (but because of "#define mmap mmap64" actually accesses
"mmap64" field).

so probably a better fix is to load "dvipng.h" after system headers,
ensuring that the same macros will apply to all code:

================================
--- texk/dvipng/misc.c
+++ texk/dvipng/misc.c
@@ -23,7 +23,6 @@

************************************************************************/

-#include "dvipng.h"
#ifdef HAVE_LIBGEN_H
# include <libgen.h>
#else
@@ -34,6 +33,7 @@
#include <sys/mman.h>
#endif
#include <sys/stat.h>
+#include "dvipng.h"

static char *programname;

================================

[Jan-Åke Larsson]

Post by Karl Berry
Vladimir found a workaround (see patch and all the details below), but I
think the cleanest solution would be to simply rename the member field.
If you'd accept that, perhaps Vladimir or I could send you a patch for
that. (Vladimir: meanwhile, I installed your change below.)

That probably would be best, name clashes are not desirable. Sorry about
that. There are no ill effects of that #define that I can tell, other
than that debugging might become cumbersome. But a struct element with
one name in one source (object) file and another in the others might be
confusing to say the least.

Post by Karl Berry
By the way, do you have any plans to make another dvipng release? I'm
sorry for not writing earlier; I'd like to get the TeX Live tree to the
other builders as soon as possible.

Oh. There are quite a few changes to the next intended release, not
least a license change (to LGPL). My schedule is kind of full at the
moment (see http://www.physorg.com/news127741035.html) but I'll see what
I can do. Deadline?

/JÅ

[Karl Berry]

Hi Jan,

That probably would be best, name clashes are not desirable.

Ok, we'll work on that.

moment (see http://www.physorg.com/news127741035.html)

Neat.

but I'll see what I can do. Deadline?

I want to give a first draft to the builders within a few days. I hope
to close things down by the end of May at the absolute latest, so, oh,
maybe a release by May 15? Very sorry for the late notice. I'll try to
do better next year.

Karl

[Jan-Åke Larsson]

Dear Karl,

May 15 is quite possible. I only really have to check that there are no
regressions, all the changes are done.

One question: do you ship dvipng linked to Freetype? ISTR this is not
the case, but it would be desirable (output quality is *much* better,
and dvipng cannot handle CJK-LaTeX without Freetype).

Best,
Jan-Åke

[Karl Berry]

May 15 is quite possible.

Great. If sooner is possible, so much the better, of course :).

One question: do you ship dvipng linked to Freetype?

As far as I can see we do configure dvipng to use the freetype2 that is
in the TL tree.

We've made lots of configure changes for TL; at some point we'll clean
those up so they'll be reasonable for you to include in the original
source, but it's not the right time for that just now.

Vladimir already put together the patch renaming the mmap struct member
to dp_mmap, so it's attached. (dp is just dvipng for short.)

Thanks,
Karl