Build failure with musl libc

[Rich Felker]

Hi,

I'm replying to this thread; sorry I don't have the original
message-id to properly thread my reply:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121231/160699.html

I am the primary author/maintainer of musl libc and I think I can shed
some light on the issue, as the original report and proposed fix was
somewhat incorrect.

Per ISO C, stdin, stdout, and stderr are macros "which are expressions
of type ''pointer to FILE'' that point to the FILE objects associated,
respectively, with the standard error, input, and output streams."
(C99 7.19.1 paragraph 3). They are not necessarily objects, merely
expressions, and as such, taking their address is invalid.

In the current definitions in musl, stdin, stdout, and stderr are
defined as follows:

extern FILE *const stdin;
extern FILE *const stdout;
extern FILE *const stderr;

#define stdin  (stdin)
#define stdout (stdout)
#define stderr (stderr)

This definition is perfectly conforming, and reflects the fact that
it's an error to attempt to assign to them. The const qualifier is on
the object itself, not the pointed-to type, and does not affect the
type of the resulting expression.

Changing DynamicLibrary.cpp to cast &stdin to (void *) would work
around the current failure, but it's not a proper fix. In fact, we're
in the middle of discussions to possibly change the above definitions
to:

#define stdin  (stdin+0)
#define stdout (stdout+0)
#define stderr (stderr+0)

which would assist the compiler in catching erroneous references to
these macros as if they were objects, by making the expression a
non-lvalue.

I can't find any documentation on DynamicLibrary.cpp and the interface
it's trying to provide, so I may be mistaken, but I believe all the
code below line 156 is simply incorrect and redundant. If stdin,
stdout, and stderr do exist as symbols, the call to dlsym at line 145
should find them. If they don't, the code below using EXPLICIT_SYMBOL
cannot work anyway.

If you're uncomfortable with removing all of that code, or know a
reason it needs to be kept, the solution I would recommend is fixing
line 163, which is using defined(__linux__) to mean "is glibc".
Changing line 163 to:

#ifdef __GLIBC__

should make the problem go away and avoid revisiting it in the future.

I'm not subscribed to the llvm lists, so please Cc me when replying if
you have any questions to address to me.

Thanks,

Rich