Undefined reference while calling GUROBI in C, Codeblocks - c

I downloaded Codeblocks to call GUROBI - an optimization package with libraries- from C. While building the example C code from GUROBI (See here), I get 15 errors in the form of:
.../main.c:32: undefined reference to `GRBloadenv#8'
.../main.c:32: undefined reference to `GRBreadmodel#12'
I already did the following:
In global compiler settings
Set Settings>Compiler>Search Directories>Compiler path to GUROBI's include folder (with .h files)
Set Search Directories>Linker path to GUROBI's lib folder (with .lib files)
Link libraries from Linker settings.
Did the same three steps above for the prject itself, i.e. Project>Build Options>...[same as Step 1]
Having spent the whole day, i cant find any solution. Any help is highly appreciated.
I'm working on Windows 10, Code::Blocks 17.12, and Gurobi 8.1.0

Related

Failing to link C code into Objective C: Undefined symbols for architecture arm64

I have some C code in my XCode project (using Objective C). I include the C file into a MyHost.m file like this:
#include <my_code.h>
And then call it like this:
my_function();
I've set up my project settings so that the Header Search Paths setting includes the directory containing my C code. However, when I build I get an error like this:
Undefined symbols for architecture arm64:
"_my_function", referenced from:
-[MyHost run] in MyHost.o
Why is the linker unable to link to the C code?
UPDATE: the reason I went down the path of using #include <file.h> instead of #include "file.h" is because the latter was failing to resolve the file. I found this related question that suggests XCode should find my header file regardless of project structure. It isn't. Even after removing and re-adding the files it still doesn't resolve it.
I had added the files as folders instead of groups. Groups are flattened by XCode and can therefore be included directly. Folders are not (but I still wasn't able to include by specifying a full path). Groups appear as yellow icons in the project view, whereas folders appear as blue.

How to solve "Undefined reference to function" in Eclipse CDT?

I did setup a C project with Eclipse Photon (4.8.0) for developing a program for the ESP-32. I did configure the IDE according to this official setup instructions.
Flashing the ESP-32 works fine. But as soon as I try to include header files from a sub folder, I run into troubles. I have set up a very simple project to illustrate the issue. The project consists of main.c, base/test.h and base/test.c, whereas the test.h and test.c files only contain one function with the signature void function1(void);.
When I try to call function1() in main.c, I get this error in main.c:
Undefined reference to function1()
Please compare to the attached screenshot, where everything is depicted.
How to solve this issue?
This is not a compiler, but rather a linker error.
Note, with #includeing a header file, you only make the external function known to the compiler. You also need to link to the external function during the linking stage. Make sure you include the compiled object file that contains function1 into the link.
Seems like you need to do proper linking.
If you are linking with a library, you need to specify:
The name of the library: Project\Settings\C C++ General\Paths and Symbols\Libraries
Location where the linker should search for this library:
Project\Settings\C C++ General\Paths and Symbols\Library Paths
Important: see Note.
If you are linking with object files, add those to:
Project\Settings\C C++ Build\Settings\Linker\Miscellaneous\Other objects
Note:
If your library name is, for example, libsomething.a, than you need to specify only something as the name; so omit lib prefix and .a suffix.
If your library is not prefixed with lib, then you need to add its name prefixed with :. For example, something.a should be added as :something.a.

Using D2XX of FTDI with C

I'm trying to use ftd2xx.lib with lcc-win32 compiler but the linker fails. I used CDM v2.12.14 but also previous FTDI driverd give the same errors. I tried to compile on Windows XP and Windows7; same results.
If I link the static library I will get these kind of errors:
File ftd2xx.lib contains unknown section .text$mn.
.text section assumed
File ftd2xx.lib contains unknown section .data$r.
.data section assumed
.data$r: undefined reference to '??_7type_info##6B#'
.text$mn: undefined reference to '__imp__SetupDiGetClassDevsA#16'
.text$mn: undefined reference to '__imp__SetupDiEnumDeviceInterfaces#20'
If I link the dynamic ftd2xx.lib (with ftd2xx.dll placed in the same dir of .exe file) I will get this:
Error e:\c\ftdi_cnt\main.c 11 undefined reference to __imp__FT_Open
(Note that main.c used for this test contains just a single FT_Open() call).
Is there anyone that was able to run ftd2xx.lib with lcc-win32 compiler or that is currently using lcc-win32 and can make a quick test? Here is the latest FTDI driver. Thank you.
Finally it works!
Here is what I did:
1) Ian suggested I should use "Utils --> Import foreign library"; as a matter of fact this is the same of running from the command line:
pedump /EXP ftd2xx.lib >ftd2xx.exp
buildlib ftd2xx.exp ftd2xxy.lib
I've already tried that using for ftd2xx.lib the dynamic .lib but without success.
2) I ran pedump again, this time using the static .lib and I got a warning message about unknown dll name, so I edited the first line of ftd2xx.exp adding that name (ftd2xx.dll).
3) I defined FTD2XX_STATIC before including ftd2xx.h
4) I linked the new library ftd2xxy.lib
Note that you can't use "Utils --> Import foreign library" because you need to modify ftd2xx.exp before re-building the library.
I hope this could be helpful for others.

NASM: How to resolve these unresolved externals?

I'm trying to get started learning basic assembly with Paul A. Carter's book "PC Assembly Language." However I'm unable to run the first example Carter provides, so I'm kind of stuck until I figure this out.
I assembled the example "first.asm" without any problem, but I can't figure out how to link these files: first.obj, driver.c, asm_io.obj into an executable. In the comment section of first.asm Carter gives these instructions for creating an executable (I'm using Windows 10, VS community 2015 developer command prompt):
; Using MS C/C++
; nasm -f win32 first.asm
; cl first.obj driver.c asm_io.obj
I'm doing exactly that but I'm getting a fatal error 2 unresolved externals, _printf and _scanf. I have every necessary file that I can think of in the same directory, and I'm compiling in that directory.
Driver.c calls the function defined in and it uses a header file called "CDECL.h"; I have this file in my directory, but I don't understand much about this header file. I wonder if the problem is here. I haven't altered it or anything. I assembled asm_io.asm according to Dr. Carter's instructions.
Not too far into asm_io.asm is see this:
extern _scanf, _printf, _getchar, _putchar, _fputs
So here are the unresolved externals. Shouldn't they be defined in stdio.h? Driver.c includes stdio.h, shouldn't the linker be able to resolve these symbols be looking at stdio.h? What might I be missing?
ps. I'm new to programming in general, and this is my first stack overflow question. I'm open to any and all criticism/feedback. I'll provide more information if you need it, I just didn't want to post a massive wall of text and code if not necessary.
Welcome to SO. You need to understand:-
The difference between a header file, e.g.
foo.h // C or maybe C++ header file)
and a library, e.g.
foo.lib foo.dll // Windows
libfoo.a, libfoo.so // Unix/Linux
that implements the calling interface that is (merely) described in a header file.
The difference between compiling or assembling a source file, e.g.
bar.c // C source file
bar.asm // Assembly source, Windows
bar.s // Assembly source, Unix/Linux
to make an object file. e.g.
bar.obj // Windows
bar.o // Unix/Linux
and linking object files and libraries together make a complete executable.
Linking can succeed only if the linker is supplied with (or knows by default)
the names and locations of object files and/or libraries that provide
implementations of all the functions that are called in the program - including
functions whose calling interfaces are described in header files. Otherwise
unresolved symbol errors ensue.
Research these points and you'll quickly get yourself unstuck. See this
pretty good introductory tutorial, which although it is about getting
started with the GNU Compiler Collection rather
than with assembly language programming, will clarify the principles
and distinctions you need to grasp.

Compaq Visual Fortran - Crashes During Linking A .LIB File

When I compile with Compaq Visual Fortran, I get these errors (when it starts the linker process) that should be located in a .lib file I thought I added to the workspace:
X30XFULL.OBJ : error LNK2001: unresolved external symbol _BCON#4
X30XFULL.OBJ : error LNK2001: unresolved external symbol _RCON#16
According to where I've googled about, it looks like Compaq Visual Fortran (Version 6, FYI) can't find the library files...
My main question is, how do I use them? Could there possibly be other missing files? Here is what I've tried:
Right Click->Adding the files in the FileView window
Going under Project->Settings, Clicking the Link tab, and under the input category, adding the library files under object/library modules (bprop.lib rprop.lib) and having the Additional Library Path point to where the files are. I also did this under the Resources tab and where it says "Additional Resource Include Directories," I put the directory of where these files were located.
To cover my bases, I also put these files in where the project workspace file, where the compiled executable file would be generated, and pretty much any place I could think of that CVF might possibly look to in order to find these files.
A little background:
I have this Fortran executable that was last compiled in the 90s. From my research, it's a 16-bit compiled one which won't work on a 64-bit machine.
The original code has, at least from what we can gather, 16 bit compiled libraries. Without the original compiler, we can't figure out how to look at or use them. We also have a (semi)equivalent library file that's actually a .FOR file. For all we know, the BPROP.FOR and BPROP.LIB could be the same file (they were found in the same source code area). If we use the BPROP.FOR file, the program can compile, but we are having issues with results that we've traced down to information that is used/gathered/processed in that file.
However, we do have 32-bit versions of (what we think) are the same .lib files. So, we're trying to use that, which is what is being used to compile the Fortran executable which results in the errors above.
Found the answer, at least for me. I don't know how easy it'll be to extrapolate if anyone else finds these answers, but this is how I solved it.
With the old Fortran libraries, all I had to do was add them to the FileList view that has all of the different fortran files (.FOR, etc). I did not have to add these libraries in the settings like I mentioned, but that will work as well. Other then that, I didn't need to add any extra declarations or anything similar.
What we did find out is that the function in question (BCON and RCON) that calls those .LIB files required an additional argument. The only way I found this out was examining other source code that used those libaries, so if anyone is stuck like I was, that would be a good place to start. Alternatively, if you can read the .lib file in a hex editor, you can kind of make out functions and their arguments.
Of course, if you have the original source code for said arguments, that's even better. :)

Resources