This question is related to this thread: cygwin support for C++11 in g++4.9.2
I had the same issue:
error: ‘log2’ is not a member of ‘std’
I applied the proposed patch, only to get another error.
Including cmath here
#include <cmath>
#include <iostream>
int main()
{
std::cout << "hello" << std::endl;
}
returns this error
$ g++ -std=c++11 test.cpp
In file included from test.cpp:1:0:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/cmath:1107:11: error: '::lrintl' has not been declared
using ::lrintl;
^
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/cmath:1129:11: error: '::rintl' has not been declared
using ::rintl;
I asked for help on the cygwin IRC channel:
[23:02] <XXX> hi, has anyone had problems with gcc 4.9.2 in cygwin? i encountered the problem discussed here : https://cygwin.com/ml/cygwin/2015-03/msg00247.html
[23:03] <XXX> yet, if i apply the patch, i get another error: /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/cmath:1107:11: error: '::lrintl' has not been declared
[23:28] <YYY> long double functions are still missing on cygwin
[23:30] <XXX> so is there no way to make it work then?
[23:31] <YYY> sure, help add the missing functions to newlib/cygwin
[23:34] <XXX> i am not using any long double functions in my code -- so i assume including cmath does not work for anybody?
[23:35] <YYY> just drop the std:: instead
[23:37] <XXX> sorry, i'm not sure what you mean. remove 'std::' where ?
Sadly, the conversation ended there. I have no clue where I should 'drop std::' nor if that resolves the problem.
Can anyone help with this?
Unpatched <cmath> works fine here if I do:
auto x = log2(10);
instead of:
auto x = std::log2(10);
Perhaps that is what YYY means by 'drop std::'.
If you must use the patched <cmath>, you can either comment out the two offending lines or if you'd prefer not to modify the header any more than you already have, add some dummy definitions of rintl and lrintl before you include it. For example:
#include <stdexcept>
long double rintl(long double arg) { throw std::runtime_error("rintl not implemented"); }
long lrintl(long double arg) { throw std::runtime_error("lrintl not implemented"); }
#include <cmath>
Related
Not including the #ifndef guard to prevent multiple header file inclusions, does not throw compile error. Why is that?
// main.c
#include <stdio.h>
#include "declare.h"
#include "declare.h" //Shouldn't I get compiler error here
int main(){
printf("Hello World\n");
}
// declare.h
#define a 1 //just this define in declare.h file
Command used to compile: gcc main.c -std=c89
Including a header multiple times is not an error, either with or without guards.
Guards prevent you from redefining objects and functions, when you do so.
But you haven't done that. You've just redefined a macro with the same value it had before. Which is fine.
You can test this by just compiling the following file:
#define a 1
#define a 1
It's fine.
[C89: 6.8.3]: [..] An identifier currently defined as a macro without use of lparen (an object-like macro) may be redefined by another #define preprocessing directive provided that the second definition is an object-like macro definition and the two replacement lists are identical. [..]
Start putting more complex stuff in that header and you'll see a problem.
It seems that gcc (tried 7.2.0 and 5.4.0) does not have std::expf and std::logf - see coliru sample. Since cppreference says they were added in C++11 is there some gcc specific macro I am missing or are they in general missing in gcc?
This is a bug in libstdc++, which ships with GCC. It does not fully conform to C++17 (as of v9.1.0 in June 2019). The copyright notice on the version of <cmath> that Ubuntu uses by default says it was last updated in 2016. Version 9.1.0 does have a #if __cplusplus > 201402L section, but it doesn’t declare the identifiers required by C++17. There is an open bug report.
It never declares expf or logf (nor cosf, sinf, etc.) within the std:: namespace, even though C++17 says it shall. The C++11 standard says, “Names that are defined as functions in C shall be defined as functions in the C++ standard library,” and “Each name from the Standard C library declared with external linkage is reserved to the implementation for use as a name with extern "C" linkage, both in namespace std and in the global namespace.” However, std::expf et al. are missing from the table of functions provided by <cmath> until P0175r1 in June 2016. This was apparently an oversight, but GCC has always made them available only in the global namespace.
The libc++ library does declare them, so compiling with clang++ -std=c++17 -stdlib=libc++ should work. You can also #include <math.h> to use them in the global namespace, or use the overloaded exp(), log(), etc. on float arguments.
If you
#include <cmath>
you will get
float exp ( float arg );
double exp ( double arg );
long double exp ( long double arg );
double exp ( IntegralType arg );
float log ( float arg );
double log ( double arg );
long double log ( long double arg );
double log ( IntegralType arg );
And hence you can call just std::exp/std::log and let the compiler figure out the overload for you. If you want to call a mismatching overload (e.g. the float overload on a double variable), I find it much more explicit and clear to add a static_cast in those cases:
double bla = ...;
return std::exp(static_cast<float>(bla));
This is a strange construct any way you write it (e.g. why is bla not a float to begin with?), and hiding it in a single-letter function name suffix isn't helping anyone.
GCC's <cmath> declares the functions expf and logf and their C Library kin in the
global namespace, not std::. In std:: it declares overloads of exp and log to
the same effect.
I have spent the day searching for an answer to what should be a simple problem. I am building a c++ program to call a fairly large amount of existing fortran. I started by changing the fortran main to a subroutine and then called it with a simple c++ main. My steps look like:
gfortran -c f1.f90 f2.f90 ......
g++ -c mn.cpp
gfortran -lstdc++ -o prog.exe mn.o f1.o ....
mn.cpp started out looking like the code below, and the above steps do work ok. I get a host of linker errors if I try to link with:
g++ -lgfortran (this never works!)
Next, I tried to instantiate a simple array class (remove the 2 commented lines). This produced linker errors concerning gxx_personality_seh0, vtable, and operator new.I get similar errors if I just create an array of doubles with new (remove comment), and if I remove the call to the fortran program completely (still linking with gfortran). Obviously, -lstdc++ does not bring in all the libraries needed. Which libraries are needed and how can I get it to link them?
I am using Windows 7 with Cygwin. The libraries it links are in ...lib/x86_64-pc-cygwin/4.9.3. I can post the linker output if it would be helpful.
mn.cpp which works (code commented out) is below:
#include <string.h>
#include <stdlib.h>
//#include "array.h"
extern "C" {
void mnf90_(const char*,int);
}
int main(int argc, char* argv[]){
// Array2D A; // first derivative
static const char *feos = "d/fld9x.dat";
int npoint = 20;
// double *xc = new double[npoint];
mnf90_(feos,strlen(feos));
}
i'm using cs50 appliance.
i've tried to write a new file test.c , found as long as i include int i line, it doesn't generate a new file test, if i remove that line and make again, it can generate test file. then i made changes on the test file, it still output the original file result, no reflect the new changes.
#include <stdio.h>
#include <cs50.h>
int
main (void)
{
printf("Number: \n");
int i = GetInt();
}
it was running properly before though... anyone can help please?
Apparently your default rules for make run the compiler on test.c.
The compiler notices that you are assigning a value to variable i, but you never use that value in any way; it would normally report this as a warning.
Apparently either your compiler or make are configured in such a way that this warning becomes a fatal error to make.
The remedy is to use the variable. It looks as though you need to pick up a book on the C programming language, or follow a course, if that's not what you're doing already.
I am trying to set the sys exit call to a variable by
extern void *sys_call_table[];
real_sys_exit = sys_call_table[__NR_exit]
however, when I try to make, the console gives me the error
error: ‘__NR_exit’ undeclared (first use in this function)
Any tips would be appreciated :) Thank you
Since you are in kernel 2.6.x , sys_call_table isnt exported any more.
If you want to avoid the compilation error try this include
#include<linux/unistd.h>
however, It will not work. So the work around to "play" with the sys_call_table is to find the address of sys_call_table in SystemXXXX.map (located at /boot) with this command:
grep sys_call System.map-2.6.X -i
this will give the addres, then this code should allow you to modify the table:
unsigned long *sys_call_table;
sys_call_table = (unsigned long *) simple_strtoul("0xc0318500",NULL,16);
original_mkdir = sys_call_table[__NR_mkdir];
sys_call_table[__NR_mkdir] = mkdir_modificado;
Hope it works for you, I have just tested it under kernel 2.6.24, so should work for 2.6.18
also check here, Its a very good
http://commons.oreilly.com/wiki/index.php/Network_Security_Tools/Modifying_and_Hacking_Security_Tools/Fun_with_Linux_Kernel_Modules
If you haven't included the file syscall.h, you should do that ahead of the reference to __NR_exit. For example,
#include <syscall.h>
#include <stdio.h>
int main()
{
printf("%d\n", __NR_exit);
return 0;
}
which returns:
$ cc t.c
$ ./a.out
60
Some other observations:
If you've already included the file, the usual reasons __NR_exit wouldn't be defined are that the definition was being ignored due to conditional compilation (#ifdef or #ifndef at work somewhere) or because it's being removed elsewhere through a #undef.
If you're writing the code for kernel space, you have a completely different set of headers to use. LXR (http://lxr.linux.no/linux) searchable, browsable archive of the kernel source is a helpful resource.