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

Jump to bottom

Cannot build any version in specific environment #492

Closed
vgoldring opened this issue Jun 12, 2015 · 13 comments
Closed

Cannot build any version in specific environment #492

vgoldring opened this issue Jun 12, 2015 · 13 comments
Labels
c++ packaging & distribution

Comments

@vgoldring
Copy link

Hi, I tried to build version 2.6.1 and 3.0.0 alpha 2 Linux in C++ using:
gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15) , g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
and the same error seems to prevent installation from generating the Makefile, so later make returns:
make: *** No targets specified and no makefile found. Stop.
./configure output shows these strange missing features of C++ environment, that frankly are hard to believe:

checking for working memcmp... no
checking for working strtod... no
checking for pow... no
checking for pow in -lm... no
configure: WARNING: cannot find library containing definition of pow
checking for ftruncate... no
checking for memset... no
checking for mkdir... no
checking for strchr... no
checking for strerror... no
checking for strtol... no
checking zlib version... headers missing or too old (requires 1.2.0.4)
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking whether to check for GCC pthread/shared inconsistencies... yes
checking whether -pthread is sufficient with -shared... yes
checking whether what we have so far is sufficient with -nostdlib... no
checking whether -lpthread saves the day... yes
checking the location of hash_map... <tr1/unordered_map>
checking for library containing sched_yield... no
configure: error: in /root/source/protobuf-2.6.1': configure: error: sched_yield was not found on your system Seeconfig.log' for more details.

About zlib missing headers, yum reports:
Package zlib-1.2.3-29.el6.x86_64 already installed and latest version
which means the installation is not found by ./configure script.

But sched_yield seems to be the final blow.

Can someone please help me understand and/or fix this?

Thank you.
@bhack
Copy link

bhack commented Jun 30, 2015

👍 I got the same problem compiling with NDK.

@nothingcosmos
Copy link

I also have the same problem occurs in ubuntu14, it was resolved.
Cause is that I had to remove the installed GCC manually in "/usr/local".
GCC libraries have been left, I was resolved after delete them.

If there is experience , please try.

@ghost
Copy link

ghost commented Aug 21, 2015

Yup, same issue with NDK, any known work arounds? Working off Ubuntu btw

@fwsGonzo
Copy link

I have the same issue trying to compile with clang++-3.6 and -stdlib=libc++, for some reason

.... why does it have to be so hard to cross compile this thing.. and why does it even care that sched_yield exists? :(

EDIT: And im compiling with -DGOOGLE_PROTOBUF_NO_RTTI and im still seeing undefined references to type_info and various other RTTI elements..

@edkimmel
Copy link

Any update on this? Same problem with ndk 11

@jakirkham
Copy link

Seeing this with Mac OS 10.9 and XCode 5.0.2.

$ clang --version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

@jakirkham jakirkham mentioned this issue Mar 29, 2016
Merged
5 tasks
@scaidermern
Copy link

Got the same problem on Debian testing today trying to compile protobuf 2.6.1. It seems like there is some weird fuckup inside the configure script (additionally to the usual fuckup commonly found in these scripts). My /usr/bin/gcc and /usr/bin/g++ are linked to gcc-5 and g++-5 respectively. Nevertheless the configure script decides to go with gcc-4.9 for whatever reason. It builds some C test cases which succeed. Then it continues with C++ tests and decides to use g++-4.9. But g++-4.9 is not installed on my system. g++-4.7 and g++-5 are. Anyway, installing g++-4.9 solves the problem.

config.log attached. The day this autotools shit dies I will throw a big party.

@Evanok
Copy link

Evanok commented Oct 13, 2016

Need to cross compile protobuf with buildroot on arm target. Same issues. Tested with v2.6.1 & v3.0.0.
No solution ?

@Gerjo
Copy link

Gerjo commented Dec 2, 2016

configure: error: in '/home/gerjo/protobuf':
configure: error: sched_yield was not found on your system
See `config.log' for more details

On my system this error was fixed by running ./configure CXX=g++-4.7. Presumably this is caused by configure literally using the g++ command which isn't always defined or pointing to the compiler you'd like to use. It my case it didn't exist, so manually specifying the compiler worked.

@razvanm
Copy link

razvanm commented Jan 5, 2017

I also hit a sched_yield was not found on your system error. In my case (an Ubuntu 16.04) the configure for protobuf was trying to use c++. Symlinking the c++ to g++ fixed the problem in my case.

@mateuszolszowy1991
Copy link

You need to install gcc-c++. That should solve problem.

@gerben-s gerben-s closed this as completed Mar 9, 2017
@gerben-s gerben-s reopened this Mar 9, 2017
@gerben-s gerben-s closed this as completed Mar 9, 2017
@johanneskoester johanneskoester mentioned this issue Feb 20, 2018
Closed
4 tasks
taoso pushed a commit to taoso/protobuf that referenced this issue Aug 1, 2018
@dfawley @dsnet
jsonpb: fix handling of illegal and negative nanoseconds (protocolbuf…
ac606b1 
…fers#492)

The documentation for Timestamp.nanos says:
<<<
Non-negative fractions of a second at nanosecond resolution. Negative
second values with fractions must still have non-negative nanos values
that count forward in time. Must be from 0 to 999,999,999
inclusive.
>>>

The documentation for Duration.nanos says:
<<<
Signed fractions of a second at nanosecond resolution of the span
of time. Durations less than one second are represented with a 0
`seconds` field and a positive or negative `nanos` field. For durations
of one second or more, a non-zero value for the `nanos` field must be
of the same sign as the `seconds` field. Must be from -999,999,999
to +999,999,999 inclusive.
>>>

Thus, we forbid values beyond the documented range of valid values.
@mkorunoski
Copy link

I was trying to cross compile it (x86_64 Ubuntu to arm64) and had the same problem. Installing both gcc-aarch64-linux-gnu and g++-aarch64-linux-gnu seems to resolve the problem. Don't rely on build-essentials to much.

@mixaz mixaz mentioned this issue Jan 9, 2019
Closed
@Patrick08T
Copy link

Thanks a lot. I have fixed the problem after I saw this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
c++ packaging & distribution
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests