2023-12-28T19:21:30Z Theo Buehler <t...@theobuehler.org>: > On Thu, Dec 28, 2023 at 06:48:52PM +0000, Johannes Thyssen Tishman wrote: >> 2023-12-28T17:58:12Z Theo Buehler <t...@theobuehler.org>: >> >>> I could use a set of eyes on this for the case that I'm missing something. >>> >>> Newer libcxx pulls in ctype.h which defines _L and _C to flag values, that >>> doesn't work well with the existing code. This results in this kind of >>> error: >>> >>> c++: warning: argument unused during compilation: '-s' >>> [-Wunused-command-line-argument] >>> /tmp/pobj/irrlamb-1.0.1/irrlamb-1.0.1r613/src/ode/src/lcp.cpp:382:33: >>> error: expected ')' >>> dReal *_pairslh, dReal *_L, dReal *_d, >>> ^ >>> /usr/include/ctype.h:46:12: note: expanded from macro '_L' >>> #define _L 0x02 >>> ^ > >> Slightly unrelated, but I'm having a similar issue with a OrocosKDL[1] >> port I'm working on (port not attached as I'm using the phone, sorry). >> I opened an issue[2] where I posted the log of a build with GCC where >> you can see similar errors. Compiling with base clang returned the >> same "error: expected ')'" errors though. > > It is the same problem and it is seen in ports occasionally. > > /usr/include/ctype.h has this: > > #define _U 0x01 > #define _L 0x02 > ... > https://github.com/openbsd/src/blob/master/include/ctype.h#L45-L52 > > To my understanding it's an old BSDism and it's used to implement > isupper(3), islower(3), etc. Someone pointed out to me that FreeBSD and > NetBSD switched to using _CTYPE_U, etc decades age. This is much less > likely to cause problems with ports. > > If you include ctype.h and use _U, _L, ... as variable name, you run > into this. To spell it out completely: > > $ cat name.c > #include <ctype.h> > > int > main(void) > { > int _L = 25; > return _L; > } > $ cc name.c > name.c:6:6: error: expected identifier or '(' > int _L = 25; > ^ > /usr/include/ctype.h:46:12: note: expanded from macro '_L' > #define _L 0x02 > ^ > 1 error generated. > > Here's what the preprocessor does: > > $ cc -E name.c | tail -n 7 > # 2 "name.c" 2 > > int > main(void) > { > int 0x02 = 25; > return 0x02; > } > > That won't work... Commenting out the #include (usually not an option > in non-toy code) or renaming the variable makes it work.
Thanks for the explanation and the example. I understand what's going on now. I will test renaming the relevant variables in my port and suggest the changes upstream.
