When I am compiling a program that requires the mondo library in D, I get slammed with a wall of errors from the linker. The last two lines, which are the only ones remotely legible are:
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
All other lines prior to it, however, essentially say the same thing: "undefined reference to ..."
I've done my research about this problem before asking on Stack Overflow, but what worked for everybody else does not seem to work for me. (Of course, I had to look up this problem with C or C++ builds, but I imagine it is not significantly different.)
Everything elsewhere on the Internet says that I need to link my libraries after compiling them to objects, but I believe I am doing that and still getting the error. The command sequence I am using looks like this:
$ dmd -c ./source/mondo/source/* insert.d
then
$ dmd insert.o mondo.o mongoc.o bsond.o
(All of the files above besides insert.o come from ./source/mondo/source/*)
The header to my program looks like this, if it is worth anything:
import mondo;
import bsond;
import mongoc;
I don't see how I can possibly be more explicit to the compiler what I want, but I still seem to get this error.
Note: mondo requires mongo-c-driver to work. I compiled that library with no issues. I tried including it by passing
-L-L/usr/local/lib
to DMD, but that did not work, either. In fact, I just get what appear to be a bunch of "undefined reference" errors for functions in that library as well!
Related
I am getting some errors I'm not really understanding, nor a solution to get around them.
I am working on a ESP32 Bluetooth connection using esp-IDF, VSCode, and PlatformIO.
I have a section of code
esp_hid_gap_init(ESP_BT_MODE_BTDM);
esp_ble_gattc_register_callback(esp_hidh_gattc_event_handler);
esp_hidh_config_t config = {
.callback = hidh_callback,
};
ESP_ERROR_CHECK( esp_hidh_init(&config) );
btkeyboard_queue_init();
ESP_ERROR_CHECK( err );
That is initialising Bluetooth and looking for connections, it requires the use of a header called bluetoothkeyboard.h which i pulled from: https://github.com/bozont/Duke3D/tree/master/components/SDL/bluetoothkeyboard
When i include this header in my main.c i get 11 errors, 10 from bluetoothkeyboard.h and one from SDL_event.h (also in the github repo i linked) they are:
The code is all unmodified and it clearly works in his demo and many others who have used it and I'm not keen on messing with a third-party library, I just don't understand what's going on and how to move around it.
Earlier it was compiling but I was getting a Collect2.exe: error: ld returned 1 exit status. To get around it I tried moving the section above into my main.c just to check but ended up in this world of pain.
I get the messages are telling me I am redefining a function, but you use the right click find all and it just references itself so I'm at a loss.
EDIT
Here is an example of one of the compiler errors:
And my CMAKE file
cmake_minimum_required(VERSION 3.16.0)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(TTGODemo)
EDIT2**
Ok so taking the comments on board, I removed the second include of BTKeyboard out of the ESP_HID_GAP.H i had. I had put it in there to cover a static constant char that was declared in only bluetoothkeyboard.h so idk how they were communicating.
That was done, I got the following wall of Text:
I think there are functions in the Bluetooth libraries that are also in the esp_hid_gap.h that it's getting hung up on. But i don't really know what to do about it, i could try removing the BT libraries but that will probably make things worse.
Thoughts?
I've had this error for weeks I already made a post about it but it wasn't very clear.
So I am calling a function from a a header file myBmpGris.h and the functions are implemented on the file myBmpGris.c . Here is my main file:
#include<stdio.h>
#include<stdlib.h>
#include "myBmpGris.h"
int main(){
char * image_name = "image_carre.bmp";
BmpImg image = readBmpImage(image_name);
return 0;
I compile by using ggc main.c and I get this error message :
Undefined symbols for architecture x86_64:
"_readBmpImage", referenced from:
_main in main-1c453a.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I read a lot of posts about the same error message but none of the answers seem to apply to my case. I'm kind of desperate because a lot of my programs give me the same error. What should I do ?
You need to tell the compiler about all the code files which contain any of the needed functions.
So if you have until now compiled like gcc main.c, then the simplest way of also getting the other file compiled is gcc main.c myBmpGris.c.
You might want to read up on the other things you can helpfully tell the compiler (and other parts of the building), i.e. the possible commandline parameters. Or use one of the available free programming environments. (I am not going to name any. Just use your favorite search engine on "C IDE free" or similar. The first few hits discuss several, try a few, then use the one your friends use, or the one you really like much, much better.)
There are two thing.
Compilation you have included. h file. It means comilper will make entry in symbol table for all used function from included library.
Linking here linker try to get address from library to fill in symbol table created in first step. This cannot be performed in your case. So give full path of library.
I am trying to port a program that uses GCD (Grand Central Dispatch) from OSX to Ubuntu 11.10. I installed libdispatch but I keep getting the following error:
undefined reference to dispatch_main()
The strange thing is that dispatch_main() is declared in a header file that I include and I call other functions declared in that header file and the compiler recognizes them. It is only dispatch_main() that it cannot see and if I call dispatch_main(2) it says that there are too many arguments, so I know the compiler can see the header.
I tried separating the compile and link steps (clang -c...) since that worked for an undefined reference error before, but it doesn't seem to do anything here...
Anybody have any suggestions? I'm pretty stumped on this one...
It sounds like you are missing the library from your link line. When you compile your program into an executable, add the library to the command. I am guessing it should look something like this:
clang x.c y.c z.c -ldispatch
When installing the Haskell GD package through cabal, on Windows (using MinGW), I get the following warnings:
Warning: resolving _gdImagePtrDestroyIfNotNull by linking to _gdImagePtrDestroyIfNotNull#4
Warning: resolving _gdImageCopyRotated90 by linking to _gdImageCopyRotated#36
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Note that these are precisely the functions defined in gd-extras.
Then, when actually compiling a Haskell program which uses gd, I get the following errors:
Linking Main.exe ...
[...]\cabal\gd-3000.7.3\ghc-7.4.1/libHSgd-3000.7.3.a(Internal.o):fake:(.text+0x2211):undefined reference to 'gdImageCopyRotated90'
[...]\cabal\gd-3000.7.3\ghc-7.4.1/libHSgd-3000.7.3.a(Internal.o):fake:(.text+0x500a):undefined reference to 'gdImagePtrDestroyIfNotNull'
[...]
collect2: ld returned 1 exit status
I'm unable to figure out how to fix this — it's already taken me ages to get to this point, as I've had many more issues trying to get it working, but this seems like the final hurdle. I have tried enabling/disabling stdcall fixup, and also changing in which file these functions are defined (as gd-extras seemed to be a potential issue), but that hasn't adressed the issues.
Thanks for any help.
You need to pass explicit linker flags to ghc, pointing to the library. The Haskell GD library is automatically linked, but the dll will not be linked as well unless you tell ghc about it. The stdcall-fixup errors are a red herring here.
I'm trying to compile the Neko VM on Mac OS X (10.5.7) using GCC 4.01 and I'm completely stuck, because it stops while compiling saying:
vm/threads.c:202: error: conflicting types for 'neko_thread_register'
vm/neko_vm.h:37: error: previous declaration of 'neko_thread_register' was here
I've tried googling this and some say it's because of lack of a "prototype" and some say it's because of a header include being done several times, and I can't really find any of those.
The affected line in threads.c:202 looks like this:
EXTERN bool neko_thread_register( bool t ) {
And the affected line in neko_vm.h:37 looks like this:
EXTERN bool neko_thread_register( bool t );
I can't see any difference in them, besides one of them being the implementation of the other.
The compiler command I'm using is:
cc -Wall -O3 -v -fPIC -fomit-frame-pointer -I vm -D_GNU_SOURCE -arch i386 -L/usr/local/lib -L/opt/local/lib -I/opt/local/include -o vm/threads.o -c vm/threads.c
I'd appreciate some ideas on what i might be able to do here, I don't really know where to go from here.
A mirror of the code for Neko which I'm trying to compile can be found here.
Thanks!
Have you tried compiling that file alone and outputting the preprocessed version? It could be that the scope or linkage macros are being modified somewhere in between the header file and the implementation file-- the same could be true of the 'bool' type, which is usually a macro defined by a system header.
According to the GCC 4.2 docs here, you should need to add the -E flag to the compilation line above, and you ought to change -o vm/threads.o to -o vm/threads.i so a file with the correct extension is created (.i means 'preprocessed file', essentially).
First, make sure you compile this as C, not C++.
Second, without seeing the code, it's pretty much impossible to say what the problem is.
But reading the error messages is often helpful (even before you google them):
Apparently neko_thread_register is declared twice, once in threads.c:202 and once in neko_vm.h:37, and the two declarations have different (conflicting) types. So look at the two declarations. If you can't see a problem with them, show us some code.
At the very least, seeing those two lines of code would be necessary. Most likely, the types are typedefs or macros or something similar, and then we'd need to see where they are defined as well.
Without seeing the code, all we can do is repeat the compiler error. "neko_thread_register has two conflicting definitions, at the lines specified."
Did you uncomment this line:
# For OSX
#
# MACOSX = 1 <-- this one
In the makefile?