Bug 45509 - imake is failing with clang
Summary: imake is failing with clang
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Build/Monolithic (show other bugs)
Version: unspecified
Hardware: Other All
: low minor
Assignee: Jeremy Huddleston Sequoia
QA Contact: Xorg Project Team
URL:
Whiteboard: 2012BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-01 10:47 UTC by Sylvestre Ledru
Modified: 2014-01-15 20:23 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvestre Ledru 2012-02-01 10:47:42 UTC
imake is failing if the C compiler used is clang.

The error is the following:

make[1]: Entering directory `/build/9menu-iFFdHM/9menu-1.8'
xmkmf
imake -DUseInstalled -I/usr/lib/X11/config
In file included from Imakefile.c:34:
In file included from /usr/lib/X11/config/Imake.tmpl:316:
/usr/lib/X11/config/Imake.rules:1674:27: error: empty character constant
        for flag in ${MAKEFLAGS} ''; do \                               @@\
                                 ^
In file included from Imakefile.c:34:
/usr/lib/X11/config/Imake.tmpl:2243:10: fatal error: ' X11 .rules' file not found
#include ProjectRulesFile
         ^
/usr/lib/X11/config/Imake.tmpl:2241:35: note: expanded from:
# define ProjectRulesFile       Concat3(<,TopLevelProject,.rules>)
                                        ^
/usr/lib/X11/config/Imake.rules:256:23: note: expanded from:
#define Concat3(a,b,c)a/**/b/**/c
                      ^
2 errors generated.

I am available for testing any chances.
Comment 1 Jeremy Huddleston Sequoia 2012-02-01 11:08:59 UTC
What do you need imake for?
Comment 2 Jeremy Huddleston Sequoia 2012-02-01 11:14:50 UTC
From https://trac.macports.org/ticket/31504

"This is because clang cannot interpret Concat3() macro properly which is declared in Imake.rules."

I'm looking into it as well.  Don't think I'm blowing you off based on the comment above ;)
Comment 3 Jeremy Huddleston Sequoia 2012-02-01 11:21:40 UTC
gcc doesn't like it either, so this doesn't seem like a clang issue:

~ $ cat test.c
#if (defined(__STDC__) && !defined(UnixCpp)) || defined(AnsiCpp)
#define Concat3(a,b,c)a##b##c
#else
#define Concat3(a,b,c)a/**/b/**/c
#endif

#define ProjectRulesFile       Concat3(<,TopLevelProject,.rules>)

ProjectRulesFile

~ $ /usr/bin/gcc -E test.c
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test.c"
# 9 "test.c"
test.c:9:1: error: pasting "<" and "TopLevelProject" does not give a valid preprocessing token
test.c:9:1: error: pasting "TopLevelProject" and "." does not give a valid preprocessing token
<TopLevelProject.rules>
Comment 4 Sylvestre Ledru 2012-02-01 13:25:10 UTC
I am using imake to build some debian packages with clang.
Thanks for digging that quickly.
Comment 5 Jeremy Huddleston Sequoia 2012-02-01 18:37:22 UTC
FWIW, you can use IMAKECPP to work around this for now:

IMAKECPP=/usr/bin/cpp xmkmf
IMAKECPP=/usr/bin/cpp make Makefiles

or /usr/lib/cpp or whatever...  setting it to "cc -E" doesn't work though.

Since it's not a clang regression over gcc at the macro level, my guess is clang is somehow going down a different cpp path than gcc.
Comment 6 Joshua Root 2012-06-01 20:18:37 UTC
The different path taken in comment 3 is due to not using -traditional like imake does. Using this option causes __STDC__ to be undefined.

In gcc it appears that -traditional implies -traditional-cpp, but clang does not support -traditional-cpp at all.

So the actual bug here is that these macros need traditional preprocessor behaviour (which apparently includes removing comments without inserting any whitespace, and ignoring empty character constants) to expand correctly, and clang does not provide that.
Comment 7 Joshua Root 2012-06-01 20:49:00 UTC
Actually, it looks like newer clang versions do accept -traditional-cpp, but apparently they still don't emulate the traditional behaviour closely enough for this code to work.
Comment 8 Mike McQuaid 2012-12-20 09:41:43 UTC
Mike from Homebrew here. Thought the patch in this pull request may be useful to you:
https://github.com/samueljohn/homebrew/commit/398110#L0R35

More discussion here:
https://github.com/mxcl/homebrew/pull/16420
Comment 9 Alan Coopersmith 2012-12-20 15:54:43 UTC
Thanks, but unless I'm missing something, the patch in
https://github.com/samueljohn/homebrew/commit/398110#L0R35
has nothing to do with what's in our imake git repo - we have no
file named imake.rb, and our configure script is autogenerated by
the GNU autoconf tool and not checked into git, nor manually edited.
Comment 10 progman3k 2014-01-15 20:23:48 UTC
Hi,
I am using imake to build a project and am affected by the bug.

I understand the workaround using the environment variable IMAKECPP to make imake use a different pre-processor, but with the combination of OSX mavericks and xcode 5, there is only one cpp on the system, clang.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.