Apparently newer versions of ubuntu (22.04 onward) do not have the Pthreads function pthread_yield but instead they include sched_yield
So my solution is to include a .c file in my project with the following function:
#include <sched.h>
int pthread_yield(void) { return sched_yield(); }
This solves my problem under ubuntu 22.04, but what about other versions where pthread_yield exists?
I would like to define this function only if it is not present in pthreads, how can I do that?
Your problem here is the simplified "not present in pthreads". What exactly is " pthreads" ?
At the basic level, pthread_yield is not part of IEEE Std 1003 (POSIX) threads.
It is declared in the GNU implementation of <pthread.h>, conditional on _GNU_SOURCE.
The implementation used to be in GUN's implementation of libpthread, but it's being moved to GNU's implementation of libc in Ubuntu 22.
Instead of using fake-POSIX functions, it's much cleaner to use the sched_yield function. It's been present for ages.
With the new comment, it sounds like you have another alternative. Linux traditionally has a library link order that's more predictable than C++ mandates.
In particular, C++ says that violating the One Definition Rule is Undefined Behavior, but ld will usually pick the first occurrence of a symbol. So just add your .o after -lpthread.
There are more complicated tricks with weak symbols but that shouldn't be necessary here.
Related
I just tried compiling code that I wrote a while ago using Gnu g++ in C++11 mode, to see if the code will need reworking anytime soon (I also plan to test it in C++17 mode for the same reason).
I found that the kill() function caused a compiler error and it seems that the kill function no longer exists in the signal.h header.
I just looked at http://www.cplusplus.com/reference/csignal/ as a reference which seems to confirm this is not just a Gnu-specific omission, but seems to be in the standard.
I can't find a rationale for this omission anywhere, nor can I find any proposal for how I should manage processes without it. Can anyone point me in the right direction?
C++ standard function is raise.
kill is a POSIX function that requires POSIX process id pid_t, none of which is required in C++ standard.
OK, I was too quick to post that question, of course fork/kill etc are not part of the C++ standard in the first place but are common additions on unix-like platforms.
My real problem was that I used the wrong compiler switch. For anyone else hitting this problem, to get strict C++11 standard, use:
g++ -std=c++11
But to get the C++11 standard plus non-standard extensions use:
g++ -std=gnu++11
Using the latter, I can build and call fork/kill no problem.
In 29.5 Atomic types of the C++ Standard November 2014 working draft it states:
There is a generic class template atomic. The type of the template argument T shall be trivially copyable (3.9). [ Note: Type arguments that are not also statically initializable may be difficult to use. —end note ]
So - as far as I can tell - this:
#include <atomic>
struct Message {
unsigned long int a;
unsigned long int b;
};
std::atomic<Message> sharedState;
int main() {
Message tmp{1,2};
sharedState.store(tmp);
Message tmp2=sharedState.load();
}
should be perfectly valid standard c++14 (and also c++11) code. However, if I don't link libatomic manually, the command
g++ -std=c++14 <filename>
gives - at least on Fedora 22 (gcc 5.1) - the following linking error:
/tmp/ccdiWWQi.o: In function `std::atomic<Message>::store(Message, std::memory_order)':
main.cpp:(.text._ZNSt6atomicI7MessageE5storeES0_St12memory_order[_ZNSt6atomicI7MessageE5storeES0_St12memory_order]+0x3f): undefined reference to `__atomic_store_16'
/tmp/ccdiWWQi.o: In function `std::atomic<Message>::load(std::memory_order) const':
main.cpp:(.text._ZNKSt6atomicI7MessageE4loadESt12memory_order[_ZNKSt6atomicI7MessageE4loadESt12memory_order]+0x1c): undefined reference to `__atomic_load_16'
collect2: error: ld returned 1 exit status
If I write
g++ -std=c++14 -latomic <filename>
everything is fine.
I know that the standard doesn't say anything about compiler flags or libraries that have to be included, but so far I thought that any standard conformant, single file code can be compiled via the first command.
So why doesn't that apply to my example code? Is there a rational why -latomic is still necessary, or is it just something that hasn't been addressed by the compiler maintainers, yet?
Relevant reading on the GCC homepage on how and why GCC makes library calls in certain cases regarding <atomic> in the first place.
GCC and libstdc++ are only losely coupled. libatomic is the domain of the library, not the compiler -- and you can use GCC with a different library (which might provide the necessary definitions for <atomic> in its main proper, or under a different name), so GCC cannot just assume -latomic.
Also:
GCC 4.7 does not include a library implementation as the API has not been firmly established.
The same page claims that GCC 4.8 shall provide such a library implementation, but plans are the first victims of war. I'd guess the reason for -latomic still being necessary can be found in that vicinity.
Besides...
...so far I thought that any standard conformant, single file code can be compiled via the first command.
...-lm has been around for quite some time if you're using math functions.
I know that the standard doesn't say anything about compiler flags or libraries that have to be included
Right.
but so far I thought that any standard conformant, single file code can be compiled via the first command.
Well, no. As you just said, there is no particular reason to assume this. Consider also that GCC extensions are enabled by default.
That being said, it seems self-evident that the intention is to make -latomic a default part of the runtime when it's settled down a bit.
g++ is a wrapper for gcc which adds the correct C++ libraries. Clearly -latomic is missing from that list. Not a core compiler problem then, simply a minor bug in the wrapper.
I am trying to compile a library using clang. The library makes calls to 'unlink', which is not defined by clang:
libmv/src/third_party/OpenExif/src/ExifImageFileWrite.cpp:162:17: error: use of undeclared identifier 'unlink'; did you mean 'inline'?
unlink( mTmpImageFile.c_str() ) ;
My question is, what is the clang equivalent of unlink? As I see it, the path forward would be to #define unlink somewhere with an equivalent routine.
There is no "Clang equivalent". Neither GCC nor Clang have ever been responsible for defining unlink, though they do probably distribute the POSIX headers which do (I don't recall specifically where POSIX headers come from).
Unfortunately, this appears to be a bug with the library you're using; the OpenExif developers failed to include the correct headers. Different C++ implementations may internally #include various headers for their own purposes, which has apparently masked this bug on your previous toolchain.
You can hack your copy and/or submit a patch to add:
#include <unistd.h>
I'd like to use unordered_set without installing Boost. I tried to add --std=gnu++0x but it is not a recognized option. Does v4.1.2 include unordered_set? If so, how do I get the header file for it?
This is a Centos 4 machine.
unordered_set is in the purview of the standard C++ library, not gcc, the compiler (although most programs built using gcc are linked against libstdc++).
The way you generally include it is #include <tr1/unordered_set>. Then, to use it, you must either do a using std::tr1::unordered_set; or qualify the name each time.
The C++ standard version you choose to use doesn't have much effect because that's the language standard, and the availability of standard library constructs is semi-independent.
IIRC, gcc-4.2 did not have unordered containers at least not in namespace std. I know -std=c++0x was not in place till around gcc-4.3.
Have you tried this:
#include <tr1/unordered_set>
...
std::tr1::unordered_set<int> usint;
...
Notice the tr1/ in the header.
Having said that, gcc-4.1 is pretty old. Any chance you could try say gcc-4.5 or 4.6 and use the std container?
I am trying to implement backtrace functionality for a large framework, which is used for different platforms and OS'es. In some of them, it is linked against glibc, while in the other, something different (eg. uclibc) is used. backtrace() function exists only in the former.
Is there any way to tell whether glibc is used? Any #define? I was unable to find an answer in glibc manual. I know I can't have linking-time information during compilation, but I guess include files have to differ. At least backtrace have to be declared somewhere.
I would like to check it without being forced to pass explicit flags to the compiler.
Include features.h, it contains the macros you need, e.g.
#define __GNU_LIBRARY__ 6
/* Major and minor version number of the GNU C library package. Use
these macros to test for features in specific releases. */
#define __GLIBC__ 2
#define __GLIBC_MINOR__ 4
There are the #defines __GNU_LIBRARY__, __GLIBC__ and __GLIBC_MINOR__ (6, 2 and 11 on my system with glibc-2.11) in features.h.
Checking for preprocessor macros is not a good solution. uClibc and possibly other libc implementations define macros to mimic glibc (without providing all of its bloated functionality) for much the same reasons that all browsers include "Mozilla" in their User-Agent strings: broken programs that expect to see glibc and turn off lots of features if they don't see it.
Instead you should write a configure script to probe for backtrace and use it only if it's available.
Empirically, both of the following compile and run fine on GCC 6.4:
#include <stdio.h>
int main(void) {
#ifdef __GLIBC__
puts("__GLIBC__");
#endif
return 0;
}
and:
int main(void) {
#ifdef __GLIBC__
puts("__GLIBC__");
#endif
return 0;
}
but only the first produces output of course.
This must mean that __GLIBC__ comes from stdio.h which must include features.h, see also: What is the purpose of features.h header?
Therefore, strictly speaking, __GLIBC__ by itself is not a clear indication that glibc is used, since even without headers, GCC already embeds runtime objects such as crt1.o in the finale executable, and those come from glibc.
So the main missing question is: does glibc guarantee that features.h gets included by every header? I could not find a clear documentation quote. TODO.
#if defined(__GLIBC__) && !defined(__UCLIBC__) && !defined(__MUSL__)
This is getting a bit ugly and syntactically ambiguous, but useful.