comparison PROBLEMS @ 1009:c7a849296cb4

[xemacs-hg @ 2002-09-20 11:32:42 by stephent] AIX macro lossage <87wupg6gph.fsf_-_@tleepslib.sk.tsukuba.ac.jp>
author stephent
date Fri, 20 Sep 2002 11:32:45 +0000
parents c017b187b1ec
children b33a835c21cc
comparison
equal deleted inserted replaced
1008:7df9b1d38660 1009:c7a849296cb4
169 when attempting to link against libMagick. The fix is to remove the old 169 when attempting to link against libMagick. The fix is to remove the old
170 libz.a in the X11 binary directory. 170 libz.a in the X11 binary directory.
171 171
172 172
173 ** AIX 173 ** AIX
174 *** IBM compiler fails: "The character # is not a valid C source character."
175
176 Most recently observed in 21.5.9, due to USE_KKCC ifdefs (they just
177 happen to tickle the implementation).
178
179 Valdis Kletnieks says:
180
181 The problem is that IBM defines a *MACRO* called 'memcpy', and we
182 have stuck a #ifdef/#endif inside the macro call. As a workaround,
183 try adding '-U__STR__' to your CFLAGS - this will cause string.h to
184 not do a #define for strcpy() to __strcpy() - it uses this for
185 automatic inlining support.
186
187 (For the record, the same issue affects a number of other functions
188 defined in string.h - basically anything the compiler knows how to
189 inline.)
190
174 *** On AIX 4.3, you must specify --with-dialogs=athena with configure 191 *** On AIX 4.3, you must specify --with-dialogs=athena with configure
175 192
176 *** The libXt shipped with AIX 4.3 up to 4.3.2 is broken. This causes 193 *** The libXt shipped with AIX 4.3 up to 4.3.2 is broken. This causes
177 xemacs -nw to fail in various ways. The official APAR is this: 194 xemacs -nw to fail in various ways. The official APAR is this:
178 195