I'm stumped. Here is the output of ld.
/usr/lib/libvisual-0.6/actor/actor_avs_superscope.so: undefined reference to `visual_mem_free'
/usr/lib/libvisual-0.6/actor/actor_avs_superscope.so: undefined reference to `visual_mem_malloc0'
Here are the macros:
#define visual_mem_new0(struct_type, n_structs) \
((struct_type *) visual_mem_malloc0 (((visual_size_t) sizeof (struct_type)) * ((visual_size_t) (n_structs))))
#define visual_mem_malloc(size) \
visual_mem_malloc_impl (size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
#define visual_mem_malloc0(size) \
visual_mem_malloc0_impl (size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
#define visual_mem_realloc(ptr, size) \
visual_mem_realloc_impl (ptr, size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
#define visual_mem_free(ptr) \
visual_mem_free_impl (ptr, __FILE__, __LINE__, __PRETTY_FUNCTION__)
Now it doesn't add up. One line's saying that visual_mem_free is missing, which is a macro. The other's saying that visual_mem_malloc0 is missing, but the code's actually calling visual_mem_new0, which suggests it sees visual_mem_new0.
priv = visual_mem_new0 (SuperScopePrivate, 1);
visual_mem_free (priv);
Any clues?
Edit: Bumping.. Maybe some fresh eyes can help?
Edit: By the way, I get no warnings/errors during compiling, nor linking.
Edit: Here's a couple of snippets from the preprocessor's output.
int lv_superscope_cleanup (VisPluginData *plugin)
{
SuperScopePrivate *priv = visual_object_get_private ((((VisObject*) ((plugin)))));
visual_mem_free_impl (priv, "actor_avs_superscope.c", 195, __PRETTY_FUNCTION__);
return 0;
}
And:
priv = ((SuperScopePrivate *) visual_mem_malloc0_impl (((visual_size_t) sizeof (SuperScopePrivate)) * ((visual_size_t) (1)), "actor_avs_superscope.c", 152, __PRETTY_FUNCTION__));
It looks like the macros are being expanded. I'm confused. Is __PRETTY_FUNCTION__ supposed to be expanded?
Interestingly enough, here's the output from strings.
$ strings .libs/actor_avs_superscope.so |grep malloc
visual_mem_malloc0_impl
visual_mem_malloc0
malloc
Chris: I'm just running ld /usr/lib/libvisual-0.6/actor/actor_avs_superscope.so.
And here's the output from nm:
$ nm actor_avs_superscope.o |grep malloc
U visual_mem_malloc0_impl
$ nm actor_avs_superscope.o |grep free
U visual_mem_free_impl
U visual_palette_free_colors
Macros in C code don't result in symbols in compiled executables. Probably what is happening is that some code you are compiling didn't #include these macros, so the compiler inferred that they were functions, and compiled calls to them. You can use -Wall and -Werror to make calls to undefined functions fail to compile.
Macros are handled during the pre-processing phase which comes before linking. So if the link-editor is giving you warnings about macro names then the macros were not expanded.
To see the results of pre-processing, you can use the /E flag. If your macros have been expanded, you would see the line:
visual_mem_free (priv);
changed to something like:
visual_mem_free_impl(priv, "filename.c", 32, "main");
Update
From your nm/strings output, the file actor_avs_superscope.o is not where the problem is. What other object (.o) files and static archives (.a) are used to create actor_avs_superscope.so? You should run nm on all of them in order to find who has the unexpanded macro name in them.
Feels like it's not reading your #defines -- try printing a message inbetween them just to check.
Also check the order of compilation of your files; does the call to visual_mem_new0 come after the #defines?
Your first error is against the installed library, /usr/lib/libvisual-0.6/actor/actor_avs_superscope.so and it looks like you are looking at the local library in your project strings .libs/actor_avs_superscope.so. Try running strings against the one in /usr/lib and you'll probably see the issue.
I'd either Install your updated library version or put it's directory in the LD_LIBRARY_PATH when you run it, something like $ LD_LIBRARY_PATH=./lib ./your_executable.
Related
I've been working on a piece of code that had an overlooked derp in it:
#include<stdio.h>
#include<stdlib.h>
#include<limits.h>
#define MAX_N_LENGTH
/*function prototypes*/
int main(){
...
}
It should be easy to spot with the context removed: #define MAX_N_LENGTH should have read #define MAX_N_LENGTH 9. I have no idea where that trailing constant went.
Since that macro was only used in one place in the form of char buf[ MAX_N_LENGTH + 1], it was extremely difficult to track down and debug the program.
Is there a way to catch errors like this one using the gcc compiler?
You can use char buf[1 + MAX_N_LENGTH], because char buf[1 +] should not compile with the error message error: expected expression before ']' token:
http://ideone.com/5m2LYw
What you have there isn't an undefined macro. It's an empty macro. And defined empty macros are perfectly legit, because you can test for their definedness.
They're used quite a lot in the implementation header files, although all those empty macros will be in the implementation namespace, which means they will either contain two underscores or an underscore followed by an uppercase letter.
What you could do is test whether you have an empty macro that's not in the implementation namespace, and you can do that with:
cpp -dM YOUR_FILE.c |
cut -d\ -f2- | grep '^[a-zA-Z0-9_]* $' |grep -v -e __ -e ^_[A-Z]
For your example, it should output just MAX_N_LENGTH.
It's not possible to catch this error in the general sense, because it isn't an error. There's plenty of cases where this sort of behavior is desired, so the compiler cannot treat it as an error or a warning.
If you can track the error down to a line, using gcc's -E command line argument will cause it to output the result of the preprocessor. In that case, your char line would have turned to char buf[+1], which is legal C code, but might catch your attention because you expected it to be char buf[9+1]. -E causes gcc to print those results, so you would actually see char buf[+1] in the output of gcc.
Issues like this are why C++ discourages use of define macros in this way (C++, of course, has more alternatives than C which makes it easier to discourage them)
You can use the preprocessor to catch when a macro is either 0 or defined without a value:
#define VAR
#if VAR+0 == 0
#error "VAR is either 0 or defined without a value."
#endif
I want to compile a c program under different names. In the main file, I have the following macro:
#ifndef EXECUTABLE_NAME
#define EXECUTABLE_NAME "defaultname"
#endif
When compiling using gcc, I use -D switch to define this macro (is that the right term?):
$ gcc main.c -DEXECUTABLE_NAME="newname"
I do not know if the -D works fine or not because when I try to do something like the code below...it fails...I can not tell if the -D switch is screwing up or the syntax of using the macro inside the printf() function is not correct:
printf("no or invalid arguments. usage: %s [0,255]\n", EXECUTABLE_NAME);
I get this error:
main.c:48:57: note: in expansion of macro ‘EXECUTABLE_NAME’
printf("no or invalid arguments. usage: %s [0,255]\n", EXECUTABLE_NAME);
Any suggestions?
It works, and you can see that because of the error. Which by the way is because you're defining your macro wrong on the command line, this is how you quote a string in a macro:
$ gcc main.c -DEXECUTABLE_NAME='"newname"'
And this said, it's not even needed. The executable path is always your first argument: *argv.
I tried this program with an integer, which is as follows
#ifndef EXECUTABLE_NAME
#define EXECUTABLE_NAME 2
#endif
int main()
{
printf("%d",EXECUTABLE_NAME);
}
and then typed gcc main.c -DEXECUTABLE_NAME=1 and it works as the value changes to 1. Is it a problem with the data type 'string' that you are using?
I like NetHack and I want to dink around with the source a bit for fun.
Before I do that I would like to be able to get it to compile out of the box but I'm having no small amount of difficulty getting that to happen.
I downloaded the source code from here and I followed the instructions here but it didn't work.
I ended up getting the following
C:\nethack-3.4.3\src>mingw32-make -f Makefile.gcc install
creating directory o
gcc -c -mms-bitfields -I../include -g -DWIN32CON -oo/makedefs.o ../util/makedefs.c
gcc -c -mms-bitfields -I../include -g -DWIN32CON -DDLB -oo/monst.o ../src/monst.c
gcc -c -mms-bitfields -I../include -g -DWIN32CON -DDLB -oo/objects.o ../src/objects.c
..\util\makedefs -v
Makefile.gcc:655: recipe for target '../include/date.h' failed
mingw32-make: *** [../include/date.h] Error -1073741819
I looked at the line it was talking about but it didn't really tell me anything. I did notice that the date.h file being created in the include directory was always empty but that doesn't help me very much either. I read the Install.nt README and the directions seemed pretty clear-cut. However since I didn't change anything I don't know why it would fail to compile...
I consider myself to be a competent programmer but I know next to nothing when it comes to makefiles and compiling C code into an executable application so I'm pretty well lost here. I downloaded and installed the MinGW... everything, by which I mean that there is nothing left uninstalled when I run the MinGW installer.
What am I doing wrong here?
EDIT : As date.h was being mentioned:
#
# date.h should be remade every time any of the source or include
# files is modified.
#
$(INCL)/date.h $(OPTIONS_FILE): $(U)makedefs.exe
$(subst /,\,$(U)makedefs -v)
I did notice it seems to be making some kind of call to OPTIONS_FILE, which seems to be commented out. I will uncomment it and see what happens.
#$(OPTIONS_FILE): $(U)makedefs.exe
#$(subst /,\,$(U)makedefs -v)
EDIT 2 That didn't work. Is it possible that I have to manually create/update the date.h file? If so, what do I put into it? Sounds like a question for Google...
EDIT 3 I found this for a much older version and tried to change it up but it didn't work either...
EDIT 4 Someone mentioned Makedefs which seems to be the thing crashing. I found the C function that appears to be causing the problem:
void
do_date()
{
long clocktim = 0;
char *c, cbuf[60], buf[BUFSZ];
const char *ul_sfx;
filename[0]='\0';
#ifdef FILE_PREFIX
Strcat(filename,file_prefix);
#endif
Sprintf(eos(filename), INCLUDE_TEMPLATE, DATE_FILE);
if (!(ofp = fopen(filename, WRTMODE))) {
perror(filename);
exit(EXIT_FAILURE);
}
Fprintf(ofp,"/*\tSCCS Id: #(#)date.h\t3.4\t2002/02/03 */\n\n");
Fprintf(ofp,Dont_Edit_Code);
#ifdef KR1ED
(void) time(&clocktim);
Strcpy(cbuf, ctime(&clocktim));
#else
(void) time((time_t *)&clocktim);
Strcpy(cbuf, ctime((time_t *)&clocktim));
#endif
for (c = cbuf; *c; c++) if (*c == '\n') break;
*c = '\0'; /* strip off the '\n' */
Fprintf(ofp,"#define BUILD_DATE \"%s\"\n", cbuf);
Fprintf(ofp,"#define BUILD_TIME (%ldL)\n", clocktim);
Fprintf(ofp,"\n");
#ifdef NHSTDC
ul_sfx = "UL";
#else
ul_sfx = "L";
#endif
Fprintf(ofp,"#define VERSION_NUMBER 0x%08lx%s\n",
version.incarnation, ul_sfx);
Fprintf(ofp,"#define VERSION_FEATURES 0x%08lx%s\n",
version.feature_set, ul_sfx);
#ifdef IGNORED_FEATURES
Fprintf(ofp,"#define IGNORED_FEATURES 0x%08lx%s\n",
(unsigned long) IGNORED_FEATURES, ul_sfx);
#endif
Fprintf(ofp,"#define VERSION_SANITY1 0x%08lx%s\n",
version.entity_count, ul_sfx);
Fprintf(ofp,"#define VERSION_SANITY2 0x%08lx%s\n",
version.struct_sizes, ul_sfx);
Fprintf(ofp,"\n");
Fprintf(ofp,"#define VERSION_STRING \"%s\"\n", version_string(buf));
Fprintf(ofp,"#define VERSION_ID \\\n \"%s\"\n",
version_id_string(buf, cbuf));
Fprintf(ofp,"\n");
#ifdef AMIGA
{
struct tm *tm = localtime((time_t *) &clocktim);
Fprintf(ofp,"#define AMIGA_VERSION_STRING ");
Fprintf(ofp,"\"\\0$VER: NetHack %d.%d.%d (%d.%d.%d)\"\n",
VERSION_MAJOR, VERSION_MINOR, PATCHLEVEL,
tm->tm_mday, tm->tm_mon+1, tm->tm_year+1900);
}
#endif
Fclose(ofp);
return;
}
Also I should mention when it gets to this point in the compile process, immediately there is this image:
So we've narrowed down the problem (I think?) to the makedefs helper program that is breaking things so now I guess the next step would be to find out why?
EDIT 5: It's been suggested that a special parameter should be used when compiling Makedefs.c. I've taken a look at the Makefile to find out where the compile takes place and I think I've found where that is happening but I don't really know what's going on here.
$(U)makedefs.exe: $(MAKEOBJS)
#$(link) $(LFLAGSU) -o$# $(MAKEOBJS)
$(O)makedefs.o: $(CONFIG_H) $(INCL)/monattk.h $(INCL)/monflag.h \
$(INCL)/objclass.h $(INCL)/monsym.h $(INCL)/qtext.h \
$(INCL)/patchlevel.h $(U)makedefs.c $(O)obj.tag
$(cc) $(CFLAGSU) -o$# $(U)makedefs.c
I know that $(*) is a variable or the Makefile equivalent of a variable.
$(U) points to $(UTIL)/, and $(UTIL) points to ../util.
$(MAKEOBJS) points to $(O)makedefs.o $(O)monst.o $(O)objects.o.
$(O) points to $(OBJ)/ which points to o so that would make $(O)makedefs.o be the same as o/makedefs.o which makes sense considering the behavior I've observed on semi-successful runs (Several files are compiled before the big freeze).
Anyway, $(link) points to gcc.
$(LFLAGSU) points to $(LFLAGSBASEC) which points to $(linkdebug) which points to -g.
$(CONFIG_H) points to a large number of header files:
CONFIG_H = $(INCL)/config.h $(INCL)/config1.h $(INCL)/tradstdc.h \
$(INCL)/global.h $(INCL)/coord.h $(INCL)/vmsconf.h \
$(INCL)/system.h $(INCL)/unixconf.h $(INCL)/os2conf.h \
$(INCL)/micro.h $(INCL)/pcconf.h $(INCL)/tosconf.h \
$(INCL)/amiconf.h $(INCL)/macconf.h $(INCL)/beconf.h \
$(INCL)/ntconf.h $(INCL)/nhlan.h
$(INCL) points to ../include.
$(CFLAGSU) points to $(CFLAGSBASE) $(WINPFLAG).
$(CFLAGSBASE) points to -c $(cflags) -I$(INCL) $(WINPINC) $(cdebug)
$(cflags) points to -mms-bitfields
$(WINPINC) points to -I$(WIN32)
$(WIN32) points to ../win/win32
$(cdebug) points to -g
$(WINPFLAG) points to -DTILES -DMSWIN_GRAPHICS -D_WIN32_IE=0x0400 . . .
And there it is. I think that's what I need to modify to make this work with what was mentioned by RossRidge -D_USE_32BIT_TIME_T.
However since I've come that far I do want to find out what some of this stuff means.
When looking at the first line I see $(U)makedefs.exe :. To me that appears to be a declaration of the target for the compiled output file? Is that correct? Also, what is the meaning of the # before the $(link) $(LFLAGSU) and after the -o$? And what is the meaning of the $ after the -o?
Anyway, I want to try what I figured out and see if it works at all.
... Aaaand adding -D_USE_32BIT_TIME_T to WINPFLAG didn't work.
FINAL(ish) EDIT: Turns out RossRidge was correct in his suggestion to use the -D_USE_32BIT_TIME_T flag. MY mistake was putting it in the wrong place. If you take a look at the Makefile.gcc that comes in the box, look at line 165 (which is in an IF statement). You want to tack -D_USE_32BIT_TIME_T at the end of that. BUT you will also want to tack it at the end of line 176 which is on the ELSE end of that IF statement. So that entire block would look something like this instead (Not a huge change, but still significant enough to make it crash if you don't do it and you're running under my situation):
################################################
# #
# Nothing below here should have to be changed.#
# #
################################################
ifeq "$(GRAPHICAL)" "Y"
WINPORT = $(O)tile.o $(O)mhaskyn.o $(O)mhdlg.o \
$(O)mhfont.o $(O)mhinput.o $(O)mhmain.o $(O)mhmap.o \
$(O)mhmenu.o $(O)mhmsgwnd.o $(O)mhrip.o $(O)mhsplash.o \
$(O)mhstatus.o $(O)mhtext.o $(O)mswproc.o $(O)winhack.o
WINPFLAG = -DTILES -DMSWIN_GRAPHICS -D_WIN32_IE=0x0400 -D_USE_32BIT_TIME_T
NHRES = $(O)winres.o
WINPINC = -I$(WIN32)
WINPHDR = $(WIN32)/mhaskyn.h $(WIN32)/mhdlg.h $(WIN32)/mhfont.h \
$(WIN32)/mhinput.h $(WIN32)/mhmain.h $(WIN32)/mhmap.h \
$(WIN32)/mhmenu.h $(WIN32)/mhmsg.h $(WIN32)/mhmsgwnd.h \
$(WIN32)/mhrip.h $(WIN32)/mhstatus.h \
$(WIN32)/mhtext.h $(WIN32)/resource.h $(WIN32)/winMS.h
WINPLIBS = -lcomctl32 -lwinmm
else
WINPORT = $(O)nttty.o
WINPFLAG= -DWIN32CON -D_USE_32BIT_TIME_T
WINPHDR =
NHRES = $(O)console.o
WINPINC =
WINPLIBS = -lwinmm
endif
(I don't know if I deserve credit for the answer, since I wouldn't have been aware of what the problem was without Harry Johnston's and indiv's comments, but I'll try to expand on the comments into a full answer.)
As indiv explained, the reason why makedefs.exe crashes is because ctime returns NULL. Normally you wouldn't expect ctime to do this, so we need to check the documentation find out under what circumstances it will return an error. Since MinGW is being used to do the compiling we need to look at Microsoft's Visual C++ documentation. This is because MinGW doesn't have it's own C runtime, it just uses Microsoft's.
Looking at at the Visual Studio C Run-Time Library Reference entry for ctime we find:
Return Value
A pointer to the character string result. NULL will be returned if:
time represents a date before midnight, January 1, 1970, UTC.
If you use _ctime32 or _wctime32 and time represents a date after 03:14:07 January 19, 2038.
If you use _ctime64 or _wctime64 and time represents a date after 23:59:59, December 31, 3000, UTC.
Now it's pretty safe to assume the original poster hasn't set his system clock to a time far into the future or long in the past. So why would ctime be using the wrong time? Harry Johnston pointed out that the code was using long instead of time_t to store time values in. This isn't too surprising. Nethack is really old code, and originally Unix stored its time in long values, using time_t for time values came later. Nethack would've had to be dealing with old systems that didn't have time_t for a significant chunl of its active development period.
That explains why the Nethack source is using the wrong type, but it doesn't quite explain why it's passing the wrong value to ctime. The fact we don't see a description of the return value for ctime itself, just _ctime32 and _ctime64 gives us a clue. If time_t is a 64-bit type, then using long instead will be a problem. On Windows long is only 32-bits, so it would mean ctime is being passed a number that's one part time value, one part random bits. Reading on in the documentation confirms this is the case, and gives us a possible solution:
ctime is an inline function which evaluates to _ctime64 and time_t is equivalent to
__time64_t. If you need to force the compiler to interpret time_t as the old 32-bit
time_t, you can define _USE_32BIT_TIME_T. Doing this will cause ctime to evaluate
to _ctime32. This is not recommended because your application may fail after January
18, 2038, and it is not allowed on 64-bit platforms
Now since defining _USE_32BIT_TIME_T only affects how the C headers are compiled, and since MinGW supplies it's own C headers, it's possible that MinGW doesn't support this. A quick check of MinGW's time.h reveals that it does, so the simple solution to use the -D_USE_32BIT_TIME_T compiler option to define this macro.
I'm attempting to refactor a piece of legacy code and I'd like a snapshot of all of the macros defined at a certain point in the source. The code imports a ridiculous number of headers etc. and it's a bit tedious to track them down by hand.
Something like
#define FOO 1
int myFunc(...) {
PRINT_ALL_DEFINED_THINGS(stderr)
/* ... */
}
Expected somewhere in the output
MACRO: "FOO" value 1
I'm using gcc but have access to other compilers if they are easier to accomplish this task.
EDIT:
The linked question does not give me the correct output for this:
#include <stdio.h>
#define FOO 1
int main(void) {
printf("%d\n", FOO);
}
#define FOO 0
This very clearly prints 1 when run, but gcc test.c -E -dM | grep FOO gives me 0
To dump all defines you can run:
gcc -dM -E file.c
Check GCC dump preprocessor defines
All defines that it will dump will be the value defined (or last redefined), you won't be able to dump the define value in all those portions of code.
You can also append the option "-Wunused-macro" to warn when macros have been redefined.
I am a unskilled programmer and new to linux, I run into a problem when complining. I have two files 'ex_addinst.c' and 'lindo.h' in the same folder, I input command :
g++ -c ex_addinst.c
then, a object file ex_addinst.o is genetated with a warning:
ex_addinst.c: In function ‘int main()’:
ex_addinst.c:80: warning: deprecated conversion from string constant to ‘char*’
then I leak them with
g++ -Wall -o ex_addinst ex_addinst.o
and get the following info:
ex_addinst.o: In function `main':
ex_addinst.c:(.text+0x2b): undefined reference to `LSloadLicenseString'
ex_addinst.c:(.text+0x75): undefined reference to `LSgetVersionInfo'
ex_addinst.c:(.text+0xae): undefined reference to `LScreateEnv'
ex_addinst.c:(.text+0x10a): undefined reference to `LSgetErrorMessage'
...
...
ex_addinst.c:(.text+0x1163): undefined reference to `LSdeleteEnv'
collect2: ld returned 1 exit status
I guess that the header file 'lindo.h' is not complied into the .o file, but I have no idea what to do now. I have tried gcc, but get the same error. the version of my g++ and gcc is 4.4.5. I am using Ubuntu 10.10.
All the functions and structures have been declared in 'lindo.h'.
part of ex_addinst.c is as follows:
#include <stdio.h>
#include <stdlib.h>
/* LINDO API header file */
#include "lindo.h"
enter code here
int CALLTYPE LSwriteMPIFile(pLSmodel pModel,
char *pszFname);
/* Define a macro to declare variables for
error checking */
#define APIERRORSETUP \
int nErrorCode; \
char cErrorMessage[LS_MAX_ERROR_MESSAGE_LENGTH] \
/* Define a macro to do our error checking */
#define APIERRORCHECK \
if (nErrorCode) \
{ \
if ( pEnv) \
{ \
LSgetErrorMessage( pEnv, nErrorCode, \
cErrorMessage); \
printf("nErrorCode=%d: %s\n", nErrorCode, \
cErrorMessage); \
} else {\
printf( "Fatal Error\n"); \
} \
exit(1); \
} \
#define APIVERSION \
{\
char szVersion[255], szBuild[255];\
LSgetVersionInfo(szVersion,szBuild);\
printf("\nLINDO API Version %s built on %s\n",szVersion,szBuild);\
}\
/* main entry point */
int main()
{
APIERRORSETUP;
pLSenv pEnv;
pLSmodel pModel;
char MY_LICENSE_KEY[1024];
/*****************************************************************
* Step 1: Create a model in the environment.
*****************************************************************/
nErrorCode = LSloadLicenseString("home/li/work/tools/lindo/lindoapi/license/lndapi60.lic", MY_LICENSE_KEY);
if ( nErrorCode != LSERR_NO_ERROR)
{
printf( "Failed to load license key (error %d)\n",nErrorCode);
exit( 1);
}
......
......
......
APIERRORCHECK;
{
int nStatus;
double objval=0.0, primal[100];
/* Get the optimization result */
nErrorCode = LSgetInfo(pModel, LS_DINFO_GOP_OBJ, &objval);
APIERRORCHECK;
LSgetMIPPrimalSolution( pModel, primal) ;
APIERRORCHECK;
printf("\n\nObjective = %f \n",objval);
printf("x[0] = %f \n",primal[0]);
printf("x[1] = %f \n",primal[1]);
/* Get the linearity of the solved model */
nErrorCode = LSgetInfo (pModel, LS_IINFO_GOP_STATUS, &nStatus);
APIERRORCHECK;
/* Report the status of solution */
if (nStatus==LS_STATUS_OPTIMAL || nStatus==LS_STATUS_BASIC_OPTIMAL)
printf("\nSolution Status: Globally Optimal\n");
else if (nStatus==LS_STATUS_LOCAL_OPTIMAL)
printf("\nSolution Status: Locally Optimal\n\n");
else if (nStatus==LS_STATUS_INFEASIBLE)
printf("\nSolution Status: Infeasible\n\n");
}
/* >>> Step 7 <<< Delete the LINDO environment */
LSdeleteEnv(&pEnv);
/* Wait until user presses the Enter key */
printf("Press <Enter> ...");
getchar();
}
part of 'lindo.h' is:
/*********************************************************************
* Structure Creation and Deletion Routines (4) *
*********************************************************************/
pLSenv CALLTYPE LScreateEnv(int *pnErrorcode,
char *pszPassword);
pLSmodel CALLTYPE LScreateModel(pLSenv pEnv,
int *pnErrorcode);
int CALLTYPE LSdeleteEnv(pLSenv *pEnv);
int CALLTYPE LSdeleteModel(pLSmodel *pModel);
int CALLTYPE LSloadLicenseString(char *pszFname, char *pachLicense);
void CALLTYPE LSgetVersionInfo(char *pachVernum, char *pachBuildDate);
Thank you!
Thank you guys answering my problem. As you suggested, I need to link the library when complining. I have gotten the executable file with:
gcc -o ex_addinst ./ex_addinst.o -L/home/li/work/tools/lindo/lindoapi/bin/linux64 -m64 -llindo64 -lmosek64 -lconsub3 -lc -ldl -lm -lguide -lpthread -lsvml -limf -lirc
but there comes another problem when run the executable file ex_addinst: after run:
./ex_addinst
there comes:
./ex_addinst: error while loading shared libraries: liblindo64.so.6.0: cannot open shared object file: No such file or directory
The tricky thing is, liblindo64.so.6.0 is in the lib folder which contains:
libconsub3.so libirc.so liblindojni.so libmosek64.so.5.0 lindo.par
libguide.so liblindo64.so liblindojni.so.6.0.3 libsvml.so placeholder
libimf.so liblindo64.so.6.0 libmosek64.so lindoapivars.sh runlindo
I have created symbolic links between liblindo64.so.6.0 and liblindo64.so with
ln -sf liblindo64.so.6.0 liblindo64.so
but it doesn't help.
Can anyone tell me what is wrong here?
(I am not sure I should put this question in a new post, but I think currently it is better to follow the old one)
Ok, lindo.h contains the prototypes for those functions, but where are the functions actually defined? If they're in another C file you need to compile that one too, and link both the object files together.
If the functions are part of another static library, you need to tell the linker to link that library along with your object file.
If they're defined with a shared library, you can probably get g++ to still link to it at compile time, and take care of the library loading etc. Otherwise you'll need to load the library at runtime and reference the functions from the library. This Wikipedia article on dynamic loading of shared libraries contains some example code.
Try
g++ -Wall -o ex_addinst ex_addinst.c
instead of
g++ -Wall -o ex_addinst ex_addinst.o
You want to compile the .c file, not the .o file.
You need to tell gcc to link with the library or object file(s) that contain the LS... functions you're using. The header file tells the compiler how to call them, but the linker needs to know where to get the compiled code from.
undefined reference to ... is not a declaration problem. The compiler fails because it can't find symbols (objects) which are related to those declared functions.
In your case, you use the Limbo API, and include the header file, but you don't tell the compiler to link with the library : that's why it doesn't find symbols.
EDIT : I had forgotten the part when you say you're new to Linux. To link with the library, you need to use the -L/-l options of g++. man g++ is always a good read, and the Limbo's documentation should be, too.