Solved

Calling a K&R-style function in C++

Posted on 2006-07-07
31
695 Views
Last Modified: 2013-11-15
Hello,

I have a library that is written in the K&R style C, so that function declarations follow the syntax:

void foo(x, y)
int x;
char y;
{ [function body] }

For each C header file, I have added:

----------------------
#ifdef __cplusplus  
extern "C" {
 #endif

[original header definitions]

 #ifdef __cplusplus
 }
 #endif
----------------------

And I'm including each header with the proper extern statement. However, I still get the following type of compilation errors:

-----------------------------------------------
/usr/local/include/lffuns.h:140: error: too many arguments to function `void foo()'
/brgordon/dev/fitting.cpp:50: error: at this point in file
make: *** [gprg.o] Error 1
-----------------------------------------------

So my question is: how do I access these old functions from a C++ program? I hope that I don't need to rewrite all the old headers into the ANSI format. I thought that the extern statements would work, but apparently not.

I would appreciate any help with this.

Thanks,
Brett
0
Comment
Question by:brgordon
  • 15
  • 11
  • 4
  • +1
31 Comments
 
LVL 12

Expert Comment

by:rajeev_devin
ID: 17063755
Can you post a more detailed code.
0
 
LVL 12

Expert Comment

by:rajeev_devin
ID: 17063759
>> So my question is: how do I access these old functions from a C++ program? I hope that I don't need to rewrite >> all the old headers into the ANSI format. I thought that the extern statements would work, but apparently not.
You can access the functions written in C and you don't have to rewrite.
The way you are doing is also fine.
BUt some more details would be helpful to understand the problem.
0
 
LVL 12

Expert Comment

by:rajeev_devin
ID: 17063768
Tell me if you did something like that

/* This is your C libray */
#include <stdio.h>
void foo(x, y)
int x;
char y;
{
   printf("%d\n", x + y); // Just for testing purpose.
}

// Here you are using the function defined in C library

extern "C" void foo(int x, char y); // It put it directly here. If you want can put it in a header file

void main()
{
   foo(10, 'a'); // using the function of C library
}
0
 
LVL 12

Expert Comment

by:rajeev_devin
ID: 17063775
usr/local/include/lffuns.h:140: error: too many arguments to function `void foo()'
/brgordon/dev/fitting.cpp:50: error: at this point in file

From this error message I can guess that in the header file you might have missed the arguments.

#ifdef __cplusplus  
extern "C" {
 #endif

void foo(int, char); // Did you put the arguments ? Because compiler is showing `void foo()'

 #ifdef __cplusplus
 }
 #endif

Let me know if I am correct.
0
 

Author Comment

by:brgordon
ID: 17064641
Rajeev,

Sorry...should have posted more detail to begin with. I am trying to access a numerical library called Locfit. The library is accessed through 4 DLLs that I was able to create and test using a simple C program. So I know the DLLs work. Other than the 4 DLLs, the library requires a number of header files that contain the structs, constants, and of course, function definitions.

Here is a sample from the function header file 'lffuns.h'
-----------lffuns.h------------------
#ifdef __cplusplus
 extern "C" {
 #endif

/* density.c */
extern int densinit(), likeden();
extern int fact[];
extern void prodintresp(), prresp();
extern int de_mint, de_itype, de_renorm;

/* dens_haz.c */
extern void haz_init();
extern int hazint();

[......]

 #ifdef __cplusplus
 }
 #endif
-------------------------------------------------

As you can see, none of the functions have any arguments in the header file.  However, here are some of the functions from "density.c" that you see in the header file:

------------density.c--------------------
void prresp(coef,resp,p)
double *coef, *resp;
int p;
{ ...... }

void prodintresp(resp,prod_wk,dim,deg,p)
double *resp, prod_wk[MXDIM][2*MXDEG+1];
int dim, deg, p;
{ ....... }

int likeden(coef, lk0, f1, A)
double *coef, *lk0, *f1, *A;
{..........}
-----------------------------------------------

For me, I'm trying to compile everything using the DLLs and header files. There is a single header file I'm supposed to include in my code called "local.h". Otherwise, I'm trying to call a few functions, specifically:

extern "C" startlf(design *, lfit *, int (*vfun)(), int);
extern "C" void lfit_init(lfit *);
extern "C" double dointpoint(lfit *, double *, int, int, int);

I have included these definitions in my functions, and used extern "C" to include the "local.h" file. However, after compiling I get the following error:

------------------------
In file included from Con.cpp:8:
fitting.cpp:22: error: expected constructor, destructor, or type conversion before ';' token
fitting.cpp: In function `void myfunction(double *)':
/usr/local/include/lffuns.h:140: error: too many arguments to function `void startlf()'
fitting.cpp:52: error: at this point in file
Con.cpp: At global scope:
Con.cpp:32: error: declaration of C function `void lfit_init(lfit*)' conflicts with
/usr/local/include/lffuns.h:140: error: previous declaration `void lfit_init()' here
Con.cpp:33: error: declaration of C function `double dointpoint(lfit*, double*, int, int, int)' conflicts with
/usr/local/include/lffuns.h:41: error: previous declaration `double dointpoint()' here
make: *** [gCon.o] Error 1
----------------------------

If I take out the arguments in the 'extern "C" void function(...)' declarations, then I just get the same error where it says I'm passing too many arguments.

Please let me know if there is any other information that is needed.

Many thanks!

-Brett

0
 

Author Comment

by:brgordon
ID: 17064654
Woops....ignore the compilation statements from above. here's the correct output:

----------------------------------------------
In file included from Con.cpp:8:
fitting.cpp:22: error: declaration of C function `void startlf(design*, lfit*, int (*)(), int)' conflicts with
/usr/local/include/lffuns.h:140: error: previous declaration `void startlf()' here
Con.cpp:32: error: declaration of C function `void lfit_init(lfit*)' conflicts with
/usr/local/include/lffuns.h:140: error: previous declaration `void lfit_init()' here
Con.cpp:33: error: declaration of C function `double dointpoint(lfit*, double*, int, int, int)' conflicts with
/usr/local/include/lffuns.h:41: error: previous declaration `double dointpoint()' here
make: *** [gCon.o] Error 1
----------------------------------

-Brett
0
 
LVL 15

Accepted Solution

by:
bpmurray earned 125 total points
ID: 17065111
You have to include the correct signatures for the functions. In other words, if you have parameters in the C source, you also have to include them in the header file, something like this below, although I've marked where I can't see the params for the functions:

ifdef __cplusplus
 extern "C" {
 #endif

/* density.c */
extern int densinit(), likeden(double, double, double, double);  /* Does densinit() have any params? */
extern int fact[];
extern void prodintresp(double*, double[][], int, int, int), prresp(double, double, int);
extern int de_mint, de_itype, de_renorm;

/* dens_haz.c */
extern void haz_init(); /* Do haz_init and hasint have any params? */
extern int hazint();

[......]

 #ifdef __cplusplus
 }
 #endif
0
 
LVL 8

Expert Comment

by:manish_regmi
ID: 17065145
The above error shows that
your decalrations in lffuns.h does not have parameters but the implementation in .cpp have .

regards
Manish
0
 

Author Comment

by:brgordon
ID: 17065194
Manish,

The implementations are not in the .cpp files, they are in the original C files in the library (included as DLLs).

bpmurray,

Do I only need to change the signatures in the C header file for functions that I'm calling from my C++ program? Or all the headers?

I tried changing only the functions I actually call. That made compilation OK, but when it got to linking, I ran into a *TON* of "undefined reference errors".
Here's my linking statement:

gcc -Wall -O3 main.cpp $(OBJS) -o dynduo  -I/usr/local/include -L/usr/local/lib -lgsl -lgslcblas -lm -lc -l liblfev -l libmut

-----------------------------------------------------------------
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x18d2): undefined reference to `std::basic_ostream<char, std::char_t
raits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x18f0): undefined reference to `vtable for std::basic_ifstream<char,
 std::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x18f5): undefined reference to `std::ios_base::ios_base()'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x18ff): undefined reference to `VTT for std::basic_ifstream<char, st
d::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1904): undefined reference to `vtable for std::basic_ifstream<char,
 std::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1910): undefined reference to `VTT for std::basic_ifstream<char, st
d::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x196b): undefined reference to `std::basic_filebuf<char, std::char_t
raits<char> >::basic_filebuf()'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x198e): undefined reference to `std::basic_ios<char, std::char_trait
s<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x19af): undefined reference to `std::basic_filebuf<char, std::char_t
raits<char> >::open(char const*, std::_Ios_Openmode)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x19d6): undefined reference to `std::basic_ios<char, std::char_trait
s<char> >::clear(std::_Ios_Iostate)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x19ef): undefined reference to `std::__basic_file<char>::is_open() c
onst'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1a44): undefined reference to `std::basic_istream<char, std::char_t
raits<char> >::operator>>(double&)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1a70): undefined reference to `std::basic_filebuf<char, std::char_t
raits<char> >::close()'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1aa2): undefined reference to `std::basic_ios<char, std::char_trait
s<char> >::clear(std::_Ios_Iostate)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1aa9): undefined reference to `std::cerr'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1ac2): undefined reference to `std::basic_ostream<char, std::char_t
raits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1aca): undefined reference to `std::basic_ostream<char, std::char_t
raits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1acf): undefined reference to `vtable for std::basic_ifstream<char,
 std::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1ad4): undefined reference to `vtable for std::basic_ifstream<char,
 std::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1ad9): undefined reference to `vtable for std::basic_filebuf<char,
std::char_traits<char> >'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1aff): undefined reference to `std::basic_filebuf<char, std::char_t
raits<char> >::close()'
/cygdrive/c/DOCUME~1/brgordon/LOCALS~1/Temp/ccfsHqBO.o:main.cpp:(.text+0x1b12): undefined reference to `std::__basic_file<char>::~__basic_fi
le()'

[MORE HERE]
----------------------------------------------------------------------

I'm going to try to figure out if these errors are due to the library or some other error. It seems odd that these basic libraries aren't being linked anymore....

-Brett
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17065259
Use g++, not gcc to compile C++ files :-)

In general, when you want to pass information on functions around in header files, you should include the full signature, i.e. with return type, name and parameter type(s). While this isn't necessary for K&R, it's required for C89 and later and for C++ (with extern "C" in this case).
0
 

Author Comment

by:brgordon
ID: 17066985
bpmurray,

I got the large set of undefined references fixed, but now I've run into something else:
----------------------------------------------------------------
g++ -Wall -O3 -ggdb main.cpp gdefines.o gfitting.o gConsumer.o gFirm.o gState.o gmtrand.o gCDFApprox.o goptimization.o -o dynduo-gdb -I/usr/local/include -L/usr/local/lib -lm -lc -lgsl -lgslcblas -l liblfev -l libmut

gConsumer.o:/home/brgordon/bg/dev/Consumer.cpp:41: multiple definition of `_lf_error'
gfitting.o:/home/brgordon/bg/dev/fitting.cpp:57: first defined here
gFirm.o: In function `vector':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:183: multiple definition of `_lf_error'
gfitting.o:/home/brgordon/bg/dev/fitting.cpp:57: first defined here
collect2: ld returned 1 exit status
make: *** [dynduo-gdb] Error 1
------------------------------------------------------

The odd thing is that I can't find a reference to "_lf_error" anywhere in my code or the library. There is a variable called "lf_error" that is used in the library, but nowhere does it appear with a "_" before it. The .cpp files above all are mine, but I don't know why it uses them. For example, fitting.cpp:57 is the end of the function that calls the numerical library, while Consumer.cpp:41 is the beginning of that classes desctructor. I have no idea where "stl_uninitialized.h" comes into play.

One thought is that I edit the original library to get rid of all references to "lf_error". I tried just changing it's name, but that didn't work. I don't need the variable for my code, and as you may have guesses, it just reports errors in the library. However, this seems like something that could be fixed without doing that.

Any ideas? If you need to see more code, please let me know what would be useful.

thanks,
Brett
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17067521
stl_uninitialised.h is a system include file (Standard Template Library?) and its references are described here: http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.4/stl__uninitialized_8h.html As you can see, it's called from other include files, which are included from gFirm.o in the function vector. It also appears to be defined in fitting.cpp.

My guess is that it's defined by some include file and I imagine you need to define something to ensure it's defined as an extern to reference the original version rather than recreating it in your files.

0
 

Author Comment

by:brgordon
ID: 17067769
bpmurray,

the original library had "lf_error" defined as an extern variable in the "local.h" include file. But whenever I tried to compile it like this, it never worked because there wasn't a file that actually defined "lf_error". The sample code did create this variable, which makes sense, but I could never get the DLLs to compile without it.

So do you think I should define something in the library or in my CPP files? like just "extern in _lf_error", or is this just the same variable "lf_error" coming up somehow?

Thanks,
Brett
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17068057
It looks like that variable is actually defined in the libs, so when you link to them, that variable is satisfied. The reason it was defined as extern was because it knew that the var would be found in the DLLs. Did you remove the "extern"? If so, that's the problem. If restoring that extern then fails with a missing variable error, you need to declare it once, not in an include file, but in a CPP file, and it needs to be declared as extern "C".
0
 

Author Comment

by:brgordon
ID: 17068978
bpmurray,

Well, there's good and bad news. The good: I seem to have fixed the lf_error/_lf_error problem. As you suggested, I included an (externed) lf_error variable in a C source file and then recompiled the library. That allowed me to successfully compile and link my main C++ program.

The bad: when I try to run the exe, the program exits immediately. I recompiled with -ggdb and set a break point for the first line in main(). The break point was never reached, but I got the following signal:

----------------------------------------
gdb: unknown target exception 0xc0000135 at 0x7c964ed1
Program received signal ?, Unknown signal.
Program exited with code 030000000465.
------------------------------------------

I tried searching online for this, but didn't find anything helpful. All the code that accesses the numerical library is done within #ifdef statements, so I switched my defines and took out all that code. This let me successfully recompile and run my program as if nothing was wrong, so the error must be due to the numerical library.

Any ideas on this?  Would I be able to use the addresses above in any way to try to figure out where in my code or the library the signal is being generated?

btw, thanks for continuing to help. I know we've kind of moved past the original question.

Thanks,
Brett
0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 
LVL 15

Expert Comment

by:bpmurray
ID: 17068991
Hmmm - I've seen this before, but only on Windows - is this Linux or Windows? If the latter, make sure you have /usr/bin in your PATH before the Windows stuff. Actually, I've seen it where I had MSVC on my path ahead of the gcc stuff.
0
 

Author Comment

by:brgordon
ID: 17069090
This is Windows. Here's my PATH:

PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files/Java/jdk1.5.0_02/bin:/cygdrive/c/Program Files/Insightful/splus70
/:/cygdrive/c/texmf/miktex/bin:/cygdrive/c/Program Files/ThinkPad/Utilities:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WIN
DOWS/System32/Wbem:/cygdrive/c/Program Files/Intel/Wireless/Bin/:/cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Pr
ogram Files/PC-Doctor for Windows/:/cygdrive/c/WINDOWS/Downloaded Program Files:/cygdrive/c/IBMTOOLS/Python22:/cygdrive/c/Program Files/MIT/
Kerberos/Bin:/cygdrive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/Program Files/Intel/Wireless/Bin/:/cygdrive/c/Program Files/Intel/Wir
eless/Bin/:/cygdrive/c/matlab_sv13/bin/win32:/cygdrive/c/Program Files/Intel/Wireless/Bin/:/cygdrive/c/Program Files/ThinkPad/ConnectUtiliti
es:/usr/lib/lapack

And here is the compilation statement:

g++ -Wall -O3 -ggdb main.cpp [object files] -o progfile.exe -I/usr/local/include -L/usr/local/lib -lm -lc -lgsl -lgslcblas -l liblfev -l libmut

Could this be due to the fact that the included libraries are .dll files, instead of .so or .a?  (or is this irrelevant?)

Brett
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17069120
Your PATH looks fine. Are the DLLs in one of the directories on the path?

It's fine for the files to be DLLs.
0
 

Author Comment

by:brgordon
ID: 17069140
The DLLs are in /usr/local/lib, so no, they are not in a directory on my path.

0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17069184
Well, they should be on your PATH (or LD_LIBRARY_PATH - not sure if that works on Windows). Otherwise, the system can't find them.
0
 

Author Comment

by:brgordon
ID: 17069279
even though I use "-L/usr/local/lib" in the g++ statement?  (that's where the gsl and gslcblas libraries are, which work fine)
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17069294
I don't know how the gcc implementation on Windows works. -L sometimes hardwires the path, and sometimes not. However, if you try setting PATH and/or LD_LIBRARY_PATH, you can see quickly if that's the problem. If it doesn't help, then that can be eliminated.
0
 

Author Comment

by:brgordon
ID: 17069310
Just tried both, but doesn't seem to work.

I'll try to get the thing working in a simple C++ program and see if that helps at all, unless you have other ideas..

0
 

Author Comment

by:brgordon
ID: 17069314
Also, I'll try to move this to a linux box and see if that helps.
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17069355
I trawled the web and it appears that this occurs occasionally. It looks like there are usually two reasons - either the version of gdb is old, or the program requires multi-threading support (-pthreads, not -lpthread).
0
 

Author Comment

by:brgordon
ID: 17069474
hmm.....well, I'm pretty sure my program needs any threads. As for gdb, here's my version:

brgordon$ gdb -v
GNU gdb 6.5.50.20060522-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".

brgordon$g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --li
ecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc --enable-nls --without-incl
d-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter -
sable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchron
tion --enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)


I just wrote a small stand-alone c++ program to try to use the library and couldn't get it to work either. I will update my version of GDB to the latest and see if that does anything.

Next thing is probably to move over to linux...
0
 

Author Comment

by:brgordon
ID: 17069994
So I tried moving it over to linux and here's what I've found:

I was able to get both a C version and CPP version of the test program running. Other than the different platforms, the only difference is that I had to use -fPIC when compiling the library. I originally tried using that on windows and cygwin, but the compiler said the option was ignored. Do you know of any reason why an alternate compiler option might be more appropriate in a CPP context?

Another question: do you know if I need both an import and export library under cygwin to use the DLL from C++?   To create the C library from cygwin, I basically followed the steps to create *only* an import library found at:

http://www.cygwin.com/cygwin-ug-net/dll.html


-Brett
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17071871
I think it really is a question of mixing & matching GDB & GCC versions - it seems they do need to sync. The -fPIC shouldn't really have an effect on any X86 machine since it has to do with the position independent code, something that's important to the Motorola & Sun's SPARC chips. One thing is important, though: you should use the same options in all your compilation units if they are to be linked together.

I'm not clear about what you did, but if you are consuming a DLL, you create an import lib that can be used to connect to the dll. This is essentially a list of entry points and their addresses and when you link that into your program, it can connect to the DLL. I don't know what an "export lib" is - I think it may be the same thing. If you're creating a DLL and want to let someone else access your functionality, you list the exports in the import lib; if you're connecting to someone else's DLL, you use their import lib to connect.
0
 

Author Comment

by:brgordon
ID: 17071911
I guess I'm not clear what GDB has to do with the problem, other than perhaps giving me the wrong error code or signal when I try to peek under the hood.

I'll look more into the DLL creation issue....I think it might be this, because cygwin seems to be fussy about how you create dlls for it.

Thanks for all your help!

-Brett
0
 
LVL 15

Expert Comment

by:bpmurray
ID: 17072229
Thanks for the points.

Apropos the gdb issue, it can only be a very few things:

1. The version of gdb you're using cannot read/process that exe: check possible conflicts between your gcc and your gdb
2. The exe is somehow corrupt: how can that happen? Different options when compiling different modules?
3. The exe fails to load the DLL(s): what does the DLL do in dllmain?
0
 

Author Comment

by:brgordon
ID: 17072318
I see what you mean about GDB, however, I know that the program isn't working independent of using GDB (A print statement is the first line in main()). So I assume that something is going wrong with linking the DLL at runtime. I think the DLL I created is meant to be a dynamically linked DLL, so this makes some sense. I think the errors in the DLL creation process under cygwin have to be the main issue.

Brett
0

Featured Post

Free Gift Card with Acronis Backup Purchase!

Backup any data in any location: local and remote systems, physical and virtual servers, private and public clouds, Macs and PCs, tablets and mobile devices, & more! For limited time only, buy any Acronis backup products and get a FREE Amazon/Best Buy gift card worth up to $200!

Join & Write a Comment

Suggested Solutions

This article describes how to use the timestamp of existing data in a database to allow Tableau to calculate the prior work day instead of relying on case statements or if statements to calculate the days of the week.
Today, still in the boom of Apple, PC's and products, nearly 50% of the computer users use Windows as graphical operating systems. If you are among those users who love windows, but are grappling to keep the system's hard drive optimized, then you s…
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.
An overview on how to enroll an hourly employee into the employee database and how to give them access into the clock in terminal.

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now