Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile fails on musl libc (Subprocess.h) #310

Closed
jprjr opened this issue Aug 28, 2015 · 4 comments
Closed

Compile fails on musl libc (Subprocess.h) #310

jprjr opened this issue Aug 28, 2015 · 4 comments

Comments

@jprjr
Copy link

jprjr commented Aug 28, 2015

Hi there -

I'm working on getting hhvm running on a musl-based Linux distro, and I'm getting an error when compiling folly:

[  3%] Building CXX object third-party/folly/CMakeFiles/folly.dir/src/folly/Subprocess.cpp.o
In file included from /builddir/hhvm-HHVM-3.9.0/third-party/folly/src/folly/Subprocess.cpp:21:0:
/builddir/hhvm-HHVM-3.9.0/third-party/folly/folly/Subprocess.h: In static member function 'static folly::Subprocess::Options folly::Subprocess::pipeStdin()':
/builddir/hhvm-HHVM-3.9.0/third-party/folly/folly/Subprocess.h:361:49: error: expected unqualified-id before '(' token
   static Options pipeStdin() { return Options().stdin(PIPE); }
                                                 ^
/builddir/hhvm-HHVM-3.9.0/third-party/folly/folly/Subprocess.h: In static member function 'static folly::Subprocess::Options folly::Subprocess::pipeStdout()':
/builddir/hhvm-HHVM-3.9.0/third-party/folly/folly/Subprocess.h:362:50: error: expected unqualified-id before '(' token
   static Options pipeStdout() { return Options().stdout(PIPE); }
                                                  ^
/builddir/hhvm-HHVM-3.9.0/third-party/folly/folly/Subprocess.h: In static member function 'static folly::Subprocess::Options folly::Subprocess::pipeStderr()':
/builddir/hhvm-HHVM-3.9.0/third-party/folly/folly/Subprocess.h:363:50: error: expected unqualified-id before '(' token
   static Options pipeStderr() { return Options().stderr(PIPE); }
                                                  ^
third-party/folly/CMakeFiles/folly.dir/build.make:767: recipe for target 'third-party/folly/CMakeFiles/folly.dir/src/folly/Subprocess.cpp.o' failed
make[2]: *** [third-party/folly/CMakeFiles/folly.dir/src/folly/Subprocess.cpp.o] Error 1
CMakeFiles/Makefile2:176: recipe for target 'third-party/folly/CMakeFiles/folly.dir/all' failed
make[1]: *** [third-party/folly/CMakeFiles/folly.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

I believe the error is that stdin, stdout, and stderr are all macros which are being expanded.

glibc defines stdin stdout stderr as:

extern struct _IO_FILE *stdin;
extern struct _IO_FILE *stdout;
extern struct _IO_FILE *stderr;
#define stdin stdin
#define stdout stdout
#define stderr stderr

musl libc defines them as:

extern FILE *const stdin;
extern FILE *const stdout;
extern FILE *const stderr;
#define stdin  (stdin)
#define stdout  (stdout)
#define stderr  (stderr)

So when compiling, lines 361-363 are expanded to:

static Options pipeStdin() { return Options().(stdin)(PIPE); }
static Options pipeStdout() { return Options().(stdout)(PIPE); }
static Options pipeStderr() { return Options().(stderr)(PIPE); }

Which leads to the above error.

I believe ISO C defines that stdin, stdout, and stderr are supposed to be macros. LLVM had some similar problem here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130506/173690.html - this post describes what stdin stdout and stderr are supposed to be better than I could.

I'm not sure what the right way to fix this is - maybe something like #undef stdin (etc) towards the beginning of the code, then redefine it towards the end?

@Orvid
Copy link
Contributor

Orvid commented Aug 29, 2015

As a note, MSVC defines stdin, stdout, and stderr as macros that call a function, so a fix here may help MSVC as well.

@zerotens
Copy link

zerotens commented Sep 1, 2015

@jprjr
You can comment these lines out until a proper fix is released.
They are just used for testing the library. (make test)

@c4milo
Copy link

c4milo commented Mar 25, 2018

I'm running into a similar issue as well with v2018.03.19.00.tar.gz release

@Orvid
Copy link
Contributor

Orvid commented Apr 4, 2018

@c4milo That is a different issue than this one, which I fixed > 1 year ago (2f6eb18). Which compiler are you trying to build with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants