Hi! while compiling texlive on AIX, i encountered problems with luatex-related files. Most of them are about variable declarations in C files which appear not at the beginning of the block. i spent a few hours on cleaning this up, and attached a patch against current texlive source tree, which changes these files: libs/luafilesystem/src/lfs.c libs/luafontforge/fontforge/Unicode/Makefile libs/luafontforge/fontforge/fontforge/Makefile libs/luafontforge/fontforge/fontforge/namelist.c libs/luafontforge/fontforge/inc/basics.h libs/luafontforge/Makefile libs/lua51/liolib.c libs/luazlib/lzlib.c texk/web2c/luatexdir/image/writepng.c texk/web2c/luatexdir/image/image.h texk/web2c/luatexdir/image/writeimg.c texk/web2c/luatexdir/lua/lcallbacklib.c texk/web2c/luatexdir/lua/loslibext.c texk/web2c/luatexdir/lua/limglib.c texk/web2c/luatexdir/lua/luatoken.c texk/web2c/luatexdir/lang/texlang.c texk/web2c/luatexdir/lang/hyphen.c texk/web2c/luatexdir/tex/postlinebreak.c texk/web2c/luatexdir/tex/texnodes.c texk/web2c/luatexdir/font/luafont.c *please* fix these portability problems, otherwise it will be painful and time consuming to do this again. attached patch is only a suggested way to fix the problem; you may choose to use slightly different approach in some case(s). please let me know if the nature of the problem(s) is not clear from the patch. Best, v.
On Sun, Apr 27 2008, Vladimir Volovich wrote:
while compiling texlive on AIX, i encountered problems with luatex-related files. Most of them are about variable declarations in C files which appear not at the beginning of the block.
Hello Vladimir, Free placement of variable declarations in C is ANSI standard since C99 and can enhance readability of C-code a lot. So, wouldn't it be much better, to just update your C-compiler on your AIX-system? (I'm not a texlive developer, so this is just my personal opinion.) Cheers, Peter -- http://pmrb.free.fr/contact/
"PM" == Peter Münster writes: PM> Free placement of variable declarations in C is ANSI standard since PM> C99 and can enhance readability of C-code a lot. PM> So, wouldn't it be much better, to just update your C-compiler on PM> your AIX-system? that's a good point, but i cannot update the compiler (it's an old AIX 4.3 system with VAC 5 compiler). if the fixes don't reduce readability of the code, i'd like to get them applied. plus, there are a few other changes in the patch, not related to variable declarations. PM> (I'm not a texlive developer, so this is just my personal opinion.) Best, v.
2008/4/27 Vladimir Volovich
plus, there are a few other changes in the patch, not related to variable declarations.
Methinks we should add this to the CFLAGS: -Wdeclaration-after-statement (C only) Warn when a declaration is found after a statement in a block. This construct, known from C++, was introduced with ISO C99 and is by default allowed in GCC. It is not supported by ISO C90 and was not supported by GCC versions before GCC 3.0. Best Martin PS: http://marc.info/?l=lua-l&m=120933425827050&w=2 :-)
"MS" == Martin Schröder writes:
plus, there are a few other changes in the patch, not related to variable declarations.
MS> Methinks we should add this to the CFLAGS: MS> -Wdeclaration-after-statement yes, that would be very helpful, if you are willing to be a bit stricter than C99 is regarding variable declarations. (this option is for gcc only, and should be used by developers to catch potential problems on systems which don't support this C99 extension). BTW, in addition to those luatex-related changes, i attahced a small patch for texk/web2c/pdftexdir/mapfile.c (we discussed that some time ago, and this is the proposed change which both works on older compilers and preserves the assert). Best, v.
Hi Vladimir, Vladimir Volovich wrote:
*please* fix these portability problems, otherwise it will be painful and time consuming to do this again.
attached patch is only a suggested way to fix the problem; you may choose to use slightly different approach in some case(s). please let me know if the nature of the problem(s) is not clear from the patch.
I am going through this now. My comments: xxx/xxx/Makefile: Patches are fine for texlive, but I will not apply these changes in the upstream. These packages do not use autoconf (yet) and I really need the -Wall etc. while developing. libs/luafilesystem/src/lfs.c: I changedthat a bit because your patch broke compilation on win32. libs/luafontforge/fontforge/inc/basics.h: what was the problem? You have commented out some typedefs, but these should be harmless. (Fontforge is upstream for me myself, so I prefer not to make changes to headers unlees absolutely necessary.) src/texk/web2c/luatexdir/font/luafont.c: one of the new "halfword next"s was a level off. Best wishes, Taco
"TH" == Taco Hoekwater writes:
TH> I am going through this now. My comments:
TH> xxx/xxx/Makefile: Patches are fine for texlive, but I will not
TH> apply these changes in the upstream. These packages do not use
TH> autoconf (yet) and I really need the -Wall etc. while developing.
TH> libs/luafilesystem/src/lfs.c: I changedthat a bit because your
TH> patch broke compilation on win32.
yeah, i didn't notice that this declaration was in the #else
conditional. i should have used this instead:
======================================
--- libs/luafilesystem/src/lfs.c
+++ libs/luafilesystem/src/lfs.c
@@ -256,6 +256,8 @@
static int dir_iter (lua_State *L) {
#ifdef _WIN32
struct _finddata_t c_file;
+#else
+ struct dirent *entry;
#endif
dir_data *d = (dir_data *)lua_touserdata (L, lua_upvalueindex (1));
luaL_argcheck (L, !d->closed, 1, "closed directory");
@@ -281,7 +283,6 @@
}
}
#else
- struct dirent *entry;
if ((entry = readdir (d->dir)) != NULL) {
lua_pushstring (L, entry->d_name);
return 1;
======================================
TH> libs/luafontforge/fontforge/inc/basics.h: what was the problem? You
TH> have commented out some typedefs, but these should be harmless.
TH> (Fontforge is upstream for me myself, so I prefer not to make
TH> changes to headers unlees absolutely necessary.)
i was getting errors:
xlc -g -c -o splinerefigure.o -I../../../../libs/luafontforge/fontforge/inc -I../../../../libs/luafontforge/fontforge/fontforge -I. -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -D_NO_PYTHON=1 -DHAVE_LANGINFO_H=1 -DX_DISPLAY_MISSING=1 -DHAVE_LONG_DOUBLE=1 -D_HAS_LONGLONG=1 -DNODYNAMIC=1 -D_NO_FREETYPE=1 -D_NO_LIBUNINAMESLIST=1 -DFONTFORGE_CONFIG_NO_WINDOWING_UI=1 -DLUA_FF_LIB=1 -UHAVE_LIBINTL_H ../../../../libs/luafontforge/fontforge/fontforge/splinerefigure.c
"../../../../libs/luafontforge/fontforge/inc/basics.h", line 48.25: 1506-334 (S) Identifier int32 has already been defined on line 624 of "/usr/include/sys/inttypes.h".
"../../../../libs/luafontforge/fontforge/inc/basics.h", line 50.25: 1506-334 (S) Identifier int16 has already been defined on line 623 of "/usr/include/sys/inttypes.h".
"../../../../libs/luafontforge/fontforge/inc/basics.h", line 52.25: 1506-334 (S) Identifier int8 has already been defined on line 622 of "/usr/include/sys/inttypes.h".
because typedefs in libs/luafontforge/fontforge/inc/basics.h
were clashing with typedefs in system header
Hi, Vladimir Volovich wrote:
TH> libs/luafontforge/fontforge/inc/basics.h: what was the problem? You TH> have commented out some typedefs, but these should be harmless. TH> (Fontforge is upstream for me myself, so I prefer not to make TH> changes to headers unlees absolutely necessary.)
i was getting errors:
Solved like this: #ifndef _AIX typedef int32_t int32; typedef int16_t int16; typedef int8_t int8; #endif For the other problem, there is a patch to web2c/coerce.h. All patched code should be checked in by the time you read this. Best wishes, Taco
"TH" == Taco Hoekwater writes: TH> Solved like this: TH> #ifndef _AIX typedef int32_t int32; typedef int16_t int16; TH> typedef int8_t int8; #endif thanks, this will work; though a better approach would be to use autoconf to test if these types are defined. (but that's not critical, and needs to be done in the upstream fontforge sources to avoid maintenance difficulties). TH> For the other problem, there is a patch to web2c/coerce.h. All TH> patched code should be checked in by the time you read this. thank you. Best, v.
participants (4)
-
Martin Schröder -
Peter Münster -
Taco Hoekwater -
Vladimir Volovich