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

Fail in make project #2

Closed
acacioegas opened this issue Sep 17, 2013 · 10 comments
Closed

Fail in make project #2

acacioegas opened this issue Sep 17, 2013 · 10 comments

Comments

@acacioegas
Copy link

/src/xkbcomp/parser.y:48.17-24: syntax error, unexpected identifier, expecting string

@bluetech
Copy link
Member

Are you building from git? If not, which version?
Can you attach the file 'config.log' from the build root?

Thanks.

@bluetech
Copy link
Member

So I can only assume you're using some yacc which is not bison. I just made some commits which adds support for recent byacc as well. I'm not aware of any other widely used yacc's.

Anything more than that is unlikely - either bison or byacc should be sufficient. Feel free to reopen if this is not the case.

@ballifatih
Copy link

Hi,

When trying to build library, I am getting similar error. I am using OS X Yosemite, and trying to port this library to MacPorts, as it is required as dependency. I attached the config.log file.

YACC     src/xkbcomp/parser.c
/Users/blue/Downloads/libxkbcommon-0.5.0/src/xkbcomp/parser.y:220.5-9: syntax error, unexpected type, expecting string or identifier
make: *** [src/xkbcomp/parser.c] Error 1

As for yacc, checking the version returns:

bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

I am using the version 5.0 from http://lists.freedesktop.org/archives/wayland-devel/2014-October/017836.html

@nuko8
Copy link
Contributor

nuko8 commented Nov 30, 2015

As @bluetech pointed out in Issue #23, Bison 2.3 is too old to compile parser.y.

I've successfully built libxkbcommon with Bison 3.0.4 on both Mavericks and El Capitan. I installed that Bison via MacPorts :-)

@ballifatih
Copy link

Yeah, after getting updated version of Bison, finally it passed the yacc parsing problem. (It took some time to realize almost every tool coming default with OS X is older versions). But now I am getting complaints that

CCLD     libxkbcommon.la
ld: unknown option: --version-script=./xkbcommon.map
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This also is a similar problem. So should I move completely away from OS X gcc compiler to GNU compiler. Or more generally, do I have to move completely to the core tools with MacPorts.

@nuko8
Copy link
Contributor

nuko8 commented Nov 30, 2015

That's the issue #24 and has already been fixed with the github version.

So should I move completely away from OS X gcc compiler to GNU compiler. Or more generally, do I have to move completely to the core tools with MacPorts.

I think you don't need to do that. The problem is simply caused by passing the wrong flag --version-script, which is unknown to clang's linker. Only dropping the flag should be fine.

@nuko8
Copy link
Contributor

nuko8 commented Nov 30, 2015

Only dropping the flag should be fine.

@bluetech committed 257e38c to fix the issue.

@ballifatih
Copy link

Indeed, dropping the flag --version-script makes compiling OK. So, it is working with Bison 3.0.4; and dropping the flag from Makefile successfully compiles( I am still 5.0 version from the stable releases).

However, when using the most recent version with cloning, I am not able to auto configure the library.

$ autoconf
configure.ac:45: error: must install xorg-macros 1.16 or later before running autoconf/autogen
configure.ac:45: the top level
autom4te: /usr/bin/m4 failed with exit status: 1

However, when I check from MacPorts, it claims that I already have the most recent version. (xorg-util-macro: 1.19). So I am guessing, the name differences between ports and libraries makes some problem, when Makefile's checking lib versions. Anyways, still 5.0 version works with dropped flag. I am planning to write a Portfile for the library, so I am still trying to get the most convenient way.

Thanks for the help :)

@nuko8
Copy link
Contributor

nuko8 commented Nov 30, 2015

$ autoconf

Instead of invoking autoconf directly, I guess you'll get a better result with

$ ./autogen.sh

at the top directory of the source tree.

@ballifatih
Copy link

Oh, it works like a charm when I use ./autogen.sh script. Then everything is fine. Thanks again :)

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