The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
But then, there comes the error: (Make:47 missing endif. Stop).
If I comment out those three lines of code, the error becomes: (<math.h> no such file or directory).
My system is OpenSUSE Leap 15.4; gcc version 7; gnu make version 4.2.1-7.3.2.
I think I have installed all the needed packages. However the errors persist. Any help?
I primarily want to address this part of the question, as the underlying issue has been addressed elsewhere, multiple times:
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
I started to write "Google led you astray", but I think it's more likely that you seriously misunderstood what it led you to. And perhaps you happened to choose poor results.
The error message indicates that you put those lines in your makefile, but they are wholly inappropriate for that. Don't put them there.
The lines are C preprocessor directives that have been stripped of their leading # characters. You would use them by restoring the # characters ...
#ifdef __linux__
#define _finite(v) (__builtin_isfinite(v))
#endif
... and putting the resulting lines into one or more of your C source files. BUT DON'T! Those lines are unnecessary and at best unhelpful.
You do need to #include <math.h> in each C source file that contains a call to isfinite(), because that is the header that provides a declaration of the function. Since C99, functions must be declared before they are called (and it was good practice well before then).
Other than that, with GCC and many other traditional-style Unix C compilers, you need to explicitly include the math library in your link when you need any of the functions it provides. That would involve adding -lm to your makefile, at the end of the gcc command that builds the final executable. This is covered in gcc will not properly include math.h, and many other duplicates on this site.
Related
I'm not really sure why "cout" and "endl" are not being recognized. Any help would be great!
The error is:
and the code is:
The fact that iostream has a red squiggle underneath it is a near certainty that you have something wrong with your environment (such as compiling with a C compiler rather than a C++ one, for example).
You need to fix that, since cout and endl are defined in that header. I'd start by hovering the mouse over the iostream text and see what the tooltip shows you.
If it cannot find the file iostream then you're either not using a C++ compiler, or your environment is severely damaged.
Either way, it's not a correct C++ environment.
Things to look in to are (to start with):
Examine the file extension. Using *.c instead of *.cpp may use a C compiler rather than a C++ one, for example).
Examine the output of your compilation, if available. You will hopefully be able to tell which compiler is being used.
If you are sure you're using a C++ compiler:
You might have a funny character in your iostream string. You could totally delete that line and retype it (don't edit, it may not get rid of the funny character).
Try a different header (like cstdlib) to see if it has the same problem.
Last-straw solution would be re-installation of your development environment, in case things are so damaged it's unrecoverable.
It's possible to override C runtime functions using the preprocessor (e.g. /Dfree=my_debug_free), however having to match the linkage of the redefined symbol is sometimes undesirable or awkward within the context of a given project.
Is there a way to force the dllimport linkage of a symbol to be satisfied with a symbol coming from a static .lib or a .obj?
Let's assume modifying the calling code directly, or defining away the __declspec keyword itself is out of the question.
Answering my own question with what I've found:
One of the things that the __declspec(dllimport) does is say that the function in question has a prefix __imp_ added to it from the importer's point of view, so manually add the prefixed function, and you satisfy the link.
As far as I understand these __imp_ are the bit that the .lib file corresponding to the .dll would normally provide. If you cut out the linking of the .lib for the .dll you cut that those also, and so have to fill in the __imp_ shaped hole manually yourself.
https://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx has a good overview.
All that said, I've found that using a pre-included file (/FI or -include) that #includes the original (unredefined) definitions first, then redefines them with #defines before entering your code works better than using /D to to redefine them everywhere, even in the original definitions. Doing it that way meas you don't need to worry about the .dll stuff.
I'm trying to link a C++ binary, but I get undefined symbol errors. My binary shouldn't need those symbols, and I'd like to understand the dependency chain causing the linker (GNU ld or GNU gold) think that they are needed. There is libfoo.a containing hundreds of .o files. My program is calling function in libfoo.a. I'd like to get a dependency graph containing all .o files in libfoo.a which the linker thinks are needed to link my program.
I need it because I suspect that there is a mistake somewhere in libfoo.a, calling functions which are not really needed. I can modify the source code of libfoo.a (and thus remove the unneeded calls), and for that I need to understand where the unneeded calls are. The dependency graph could help me find it.
Please note that there is no resulting executable, because of the undefined symbols.
Please note that my ultimate goal is not to build this particular binary, but to make sure that unneeded functions are not called in libfoo.a.
I've looked at man ld, but I couldn't find any command-line flag that could give me more verbose output.
Example error from the linker:
libfoo++.a(foo1.o):foo1.cc:function foo1f: error: undefined reference to 'bar'
How do I figure out what caused foo1.o to be linked to the executable? (It's OK for me that bar is undefined, because I don't need it. My problem is that foo1.o is needed, but it shouldn't be, and I'd like to remove the call which caused foo1.o to be linked in.)
I'd like to get a dependency graph containing all .o files in libfoo.a which the linker thinks are needed to link my program.
The linker map, printed with -M (or --print-map) flag contains exactly that info. If you are using compiler driver (e.g. gcc) to perform the link (you should), then add -Wl,-M to the link line.
Is it possible to DISABLE source code view in backtrace, to display only line numbers and file names?
I mean do NOT include these informations to application, because you can also read from the application file.
I don't want anyone to see my source code.
If it's impossible in GDB, is there any other debugger with such feature?
GDB can only show your source code if it can find your original source files. If people can see your source in the backtrace, then presumably they can also see your entire source base.
Therefore, I suspect you mean that you do not want the compiler to include any of your sources in the application binaries?
In fact, the application binaries only contain the source filenames, line numbers, symbol names (such as function and variable names), and some type information. If you use -g3 then they might also include preprocessor macros, but most people just use -g.
The easiest way to exclude the 'source' information is to not ship binaries with debug information. You can either build it without using -g in the first place, or you can use strip to remove it after the fact.
Not building with debug info will remove all symbol names that are not absolutely necessary (including static functions, and all local variable names), but it will not remove the symbol names for externally visible functions: the linker needs to see those. strip can remove some of those also, I think, although I've never tried. Beware that libraries must have symbol names for externally visible function.
Removing debug info will also remove line-number information, and source file names, so this still isn't quite what you want.
I'd suggest a) refactoring your source code so that isn't embarrassing and/or give away any clues, and b) don't ship with debug info.
is there a way i can print __FUNCTION__ as a wide character on linux?
the trick with the WIDEN doesn't work for me, the gcc compiler prints:
error: ?L_FUNCTION_? was not declared in this scope
any help?
Thanks
7+ years later (although things seem to be the same) ...
Since you mentioned gcc, check [GNU.GCC]: Standard Predefined Macros (emphasis is mine):
C99 introduced __func__, and GCC has provided __FUNCTION__ for a long time. Both of these are strings containing the name of the current function (there are slight semantic differences; see the GCC manual). Neither of them is a macro; the preprocessor does not know the name of the current function.
Since __FUNCTION__ is not a macro (the preprocessor doesn't "know" anything about it), it will remain untouched during (outer) macro expansion, generating at the end the L__FUNCTION__ identifier, which is obviously invalid. That's why the double macro approach works for __FILE__ (for example), but not for __FUNCTION__ (or __func__).
So, the short answer to your question is "NO" (at least not at preprocessor level). You will need to convert __FUNCTION__ "manually" (e.g. using one of the [man7]: MBSTOWCS(3) functions family).
Note: It works on VStudio, since according to [MS.Docs]: Predefined Macros (emphasis still mine):
__FUNCTION__ Defined as a string literal that contains the undecorated name of the enclosing function. The macro is defined only within a function.
It can be done using macros, you just have to understand how macros expand.
To get a wide char version of the macro you need to create 2 layers of macros like so:
#define WIDE2(x) L##x
#define WIDECHAR(x) WIDE2(x)
#define WIDE_FUNCTION WIDECHAR(__FUNCTION__)
The all important piece is the L##x that appends the L character to the string constant before the compiler sees it. You can do this to __FILE__ as well using the same technique.
That looks more like a typo of __FUNCTION__ than an issue with widen() or similar, at least if you pasted the exact error message.