I am trying to link a c program that I compiled with the gcc compiler. The linker does not find the symbol tdestroy which is a gnu extension to libc (#define __USE_GNU followed by #include <search.h>). Is there an additional library that I have to link with in order for the linker to find this symbol?
~Update~: I just realized that it does indeed link on my Linux environment but on Windows, I still get a undefined reference to 'tdestroy' error with mingw/gcc, even after using _GNU_SOURCE instead of __USE_GNU.
Don't use __USE_GNU. That's an internal GLIBc macro. The tdestroy man page says the macro you need
to define at the beginning is _GNU_SOURCE.
#define _GNU_SOURCE
#include <search.h>
void *td = tdestroy;
int main(){}
compiles with no linker error (no extra libraries needed).
You should never define __USE_GNU (sic), it is an internal symbol. You need to define _GNU_SOURCE, see Feature Test Macros.
If you do that, the tdestroy function will become available.
It is also a good idea to build with -Werror=implicit-function-declaration, so that missing prototypes lead to a compiler failure, and not later to a linker failure.
Related
I have downloaded libgcrypt library source code and I want to customize this standard shared library by adding my function inside one particular
source code file .
Although compilation/build process of customized shared library is successful, but it shows error at linking time.
Here is what I have done .
inside /src/visibility.c file, I have added my custom function,
void MyFunction(void)
{
printf("This is added just for testing purpose");
}
I have also include function prototype inside /src/gcrypt.h
void MyFunction(void);
#build process
./configure --prefix=/usr
sudo make install
nm command find this custom function.
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Here is my sample code to access my custom function.
//aes_gcrypt_example.c
#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>
int main()
{
MyFunction();
return 0;
}
gcc aes_gcrypt_example.c -o aes -lgcrypt
/tmp/ccA0qgAB.o: In function `main':
aes_gcrypt_example.c:(.text+0x3a2): undefined reference to `MyFunction'
collect2: error: ld returned 1 exit status
I also tried by making MyFunction as extern inside gcrypt.h, but in that case also I am getting same error.
Why is this happening ?
Is the customization of standard library is not allowed ?
If YES, then is there any FLAG to disable to allow customization ?
If NO, what mistake I am making ?
It would be great help if someone provide some useful link/solution for the above mentioned problem. I am using Ubuntu16.04 , gcc 4.9.
Lower-case t for the symbol type?
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Are you sure that's a visible function? On my Ubuntu 16.04 VM, the linkable functions defined in an object file have T (not t) as the symbol type. Is there a stray static kicking around and causing confusion? Check a couple of other functions defined in libgcrypt.so (and documented in gcrypt.h) and see whether they have a t or a T. They will have a T and not t. You'll need to work out why your function gets a t — it is not clear from the code you show.
The (Ubuntu) man page for nm includes:
The symbol type. At least the following types are used; others
are, as well, depending on the object file format. If lowercase,
the symbol is usually local; if uppercase, the symbol is global
(external).
The line you show says that MyFunction is not visible outside its source file, and the linker agrees because it is not finding it.
Your problem now is to check that the object file containing MyFunction has a symbol type T — if it doesn't the problem is in the source code.
Assuming that the object file shows symbol type T but the shared object shows symbol type t, you have to find what happens during the shared object creation phase to make the symbol invisible outside the shared object. This is probably because of a 'linker script' that controls which symbols are visible outside the library (or maybe just compilation options). You can search on Google with 'linker script' and various extra words ('tutorial', 'provide', 'example', etc) and come up with links to the relevant documentation.
You may need to research documentation for LibTool, or for the linker BinUtils. LibTool provides ways of manipulating shared libraries. In a compilation command line that you show in a comment, there is the option -fvisibility=hidden. I found (mostly by serendipitous accident) a GCC Wiki on visibility. See also visibility attribute and code generation options.
What is the purpose of the features.h header? Why and when can it be used in my code?
Does it define source features supported by the system?
Or does it define some additional things which must be defined depending on other defines?
The features.h header file provides various macro definitions that indicate standard conformance to other header files, i.e. which features (hence the name) should be turned on or off depending on which standard the user wishes to use.
Most C/C++ compilers have command line options to handle standards conformance. Let's take GCC as an example: when you pass the -std=gnu9x option, you ask for the GNU dialect of the C99 standard. The features.h header makes sure that all other headers that include it will turn exactly those features on or off that are needed to support this particular dialect. This is achieved by #define -ing or #undef - ing some "intermediate" macros.
As a bonus, features.h also provides the glibc version information macros as well, and various other bits & bobs.
I have grepped POSIX 7 as explained at: https://unix.stackexchange.com/questions/340285/install-the-latest-posix-man-pages/483198#483198 and there are no hits for features.h, so it must be a glibc extension only.
In glibc 2.28, it is present at include/features.h.
One of the interesting things that it defines are version macros:
#include <stdio.h>
#include <features.h>
int main(void) {
printf("__GLIBC__ %u\n", __GLIBC__);
printf("__GLIBC_MINOR__ %u\n", __GLIBC_MINOR__);
return 0;
}
Ubuntu 16.04, which has glibc 2.23, this outputs:
__GLIBC__ 2
__GLIBC_MINOR__ 23
See also: Check glibc version for a particular gcc compiler
Also, this header seems to get included in most / all glibc headers, which might allow you to check if glibc is being used: How to tell if glibc is used but TODO I couldn't find a documentation for that.
From features.h File Reference
Defines on whether to include algorithm variants.
Less variants reduce executable size and compile time. This file is a GNU parallel extension to the Standard C++ Library.
So this file will include some algorithm listed in the reference page.
In general if you need to use any of the variables or functions defined in a header file, you need to include it in your program. This rule is valid for features.h also. You can see a URL for features.h for your reference below:
http://repo-genesis3.cbi.utsa.edu/crossref/heccer/usr/include/features.h.html
Consider the following code snippet:
#include <linux/interrupt.h>
DECLARE_TASKLET (test_tasklet, test_func, (unsigned long) &test_data);
from what ld does know which library or object-file must be linked with our source file?
from what ld does know which library or object-file must be linked with our source file?
It doesn't. You must specify required libraries and object files to the linker.
You are possibly thinking of Microsoft #pragma comment(lib, ...), which doesn't exist in any other compiler I know of.
This is part of a series of at least two closely related, but distinct questions. I hope I'm doing the right thing by asking them separately.
I'm trying to get my Visual C++ 2008 app to work without the C Runtime Library. It's a Win32 GUI app without MFC or other fancy stuff, just plain Windows API.
So I set Project Properties -> Configuration -> C/C++ -> Advanced -> Omit Default Library Names to Yes (compiler flag /Zl) and rebuilt. Let's pretend I have written a suitable entry point function, which is the subject of my other question.
I get two linker errors; they are probably related. The linker complains about unresolved external symbols __fltused and _memcpy in foobar.obj. Needless to say, I use neither explicitly in my program, but I do use memcpy somewhere in foobar.cpp. (I would have used CopyMemory but that turns out to be #defined to be identical to memcpy...)
(I thought I could get rid of the memcpy problem by using a compiler intrinsic, like #pragma intrinsic(memcpy), but this makes no difference.)
If I look at the preprocessor output (adding /P to the compiler command line), I see no references to either __fltused or _memcpy in foobar.i.
So, my question is: Where do these linker errors come from, and how do I resolve them?
__fltused implies you are using or have at least declared some floats or doubles. The compiler injects this 'useless' symbol to cause a floating support .obj to get loaded from the crt. You can get around this by simply declaring a symbol with the name
#ifdef __cplusplus
extern "C" {
#endif
int _fltused=0; // it should be a single underscore since the double one is the mangled name
#ifdef __cplusplus
}
#endif
WRT _memcpy - memcpy is a __cdecl function, and all cdecl functions get an automatic _ as part of their decoration. so, when you say "__cdecl memcpy" - the compiler & linker go looking for a symbol called '_memcpy'. Intrinsic functions - even explicitly requested - can still be imported if the build settings have debug settings that contra-indicate intrinsics. So you are going to need to implement your own memcpy and related functions at some point anyway.
I recommend setting the "generate assembly listing" (or some such) compiler option for foobar.cpp once, and then inspecting the assembler code. This should really tell you where these symbols are used.
While migrating a program from windows in linux I encountered a problem using the c++ standard template library. I am trying to typedef a template and I am getting the error 'expected initializer before '<' token on this line
typedef std::list< std::pair< int,double> > PairList;
Any ideas why this would work using mvc++ and not using g++ and how I can fix it?
I think this is about #includes.
The following really minimal piece of code compiles perfectly here with g++ on Linux
#include <utility>
#include <list>
typedef std::list< std::pair< int,double> > PairList;
PairList x;
One thing to remember about standard include files is that they are allowed but not required to call each other. (It's not like they're potentially polluting the namespace by this, since they all use namespace std, which you aren't supposed to mess with.)
It is possible that, in MSVC++, includes , or vice versa, but this is not the case in the g++ headers. Therefore, a program might compile in MSVC++ and not in g++, with a required header missing in the source.
Make sure all of your required headers are actually included, and you should be fine.
Did you #include <utility> for pair?
I have had no problems with the code in G++, and generally found its STL support to be superb. Do you have all the #include directives there? Sometimes those differ from platform to platform (even when they shouldn't).