Home » Language IDEs » C / C++ IDE (CDT) » Debugging Shared Libraries
| Debugging Shared Libraries [message #116757] |
Mon, 23 August 2004 23:57  |
Eclipse User |
|
|
|
I'm having an impossible time trying to debug a simple hello world
application that gets it's "hello world" string from a shared library.
Here are the symptoms of the patients illness:
1. If I create JUST a main and link with no shared libraries, I can launch
the debugger, set breakpoints, etc. (I'm running g++ on Cygwin under
Win32).
2. If a link with ANY shared library, when I launch the debugger through
Eclipse, I get the "Run in Background" dialog and it just sites there
forever while the little blue progress thing flashes in the lower right
corner.
3. On numerous occasions, the entire IDE just ABENDS (faults and disapears
completely) if I attempt debugging when linked with a shared lib.
The workspace contains two projects: a main, created as an "Executable -
Cygwin" and another shared library project, that I created as a "GNU
Shared DLL".
The program RUNS fine when linked with the DLL - but how does one debug
when linked with a shared lib?
-- Dave
|
|
| | | | |
| Re: Debugging Shared Libraries [message #116942 is a reply to message #116757] |
Tue, 24 August 2004 11:29  |
| Eclipse User |
|
|
|
David,
I do not have anywhere near as much trouble as you are reporting.
Granted, I am using a simple example right now, but I build a DLL as a
standard project, link it into a managed C++ project, and I can step
into the DLL no trouble. Why don't we start with the simple case first,
then work out from there.
I use the latest stuff I downloaded from Cygwin:
kernel: 1.5.10
/usr/bin/g[cc|++]: 3.3.3
/usr/bin/gdb: 2003-09-20-cvs
I build the DLL source with the following arguments:
g++ -O -g -DMAKEDLL -Wall -c -fmessage-length=0 -o $@ $<
and the DLL/export lib with:
g++ -shared -Wl,--out-implib=libmsgs.dll.a -Wl,--output-def=msgs.def -o
$@ $^
The main project includes the right header from the DLL project and gets
built with USEDLL defined (the header has the following in it)
#if defined(MAKEDLL)
# define DLLEXPORT __declspec(dllexport)
#elif defined(USEDLL)
# define DLLEXPORT __declspec(dllimport)
#else
# define DLLEXPORT
#endif
It links in the library that is built (lib<name>.dll.a) and after the
build I copy the cyg<name>.dll into the directory where the EXE is located.
From there, the only grief I get is when I try to step into methods in
the system libraries (like trying to step into a call on basic_string).
I realize that you are frustrated and you had hoped to find a commercial
quality IDE, but before you give up all hope, let's at least eliminate
the possiblity that some of your problems are relted to how the project
is being built (or a missing intermediate step).
Sean
dwa wrote:
> I'm having an impossible time trying to debug a simple hello world
> application that gets it's "hello world" string from a shared library.
> Here are the symptoms of the patients illness:
>
> 1. If I create JUST a main and link with no shared libraries, I can launch
> the debugger, set breakpoints, etc. (I'm running g++ on Cygwin under
> Win32).
>
> 2. If a link with ANY shared library, when I launch the debugger through
> Eclipse, I get the "Run in Background" dialog and it just sites there
> forever while the little blue progress thing flashes in the lower right
> corner.
>
> 3. On numerous occasions, the entire IDE just ABENDS (faults and disapears
> completely) if I attempt debugging when linked with a shared lib.
>
> The workspace contains two projects: a main, created as an "Executable -
> Cygwin" and another shared library project, that I created as a "GNU
> Shared DLL".
>
> The program RUNS fine when linked with the DLL - but how does one debug
> when linked with a shared lib?
>
> -- Dave
>
>
>
>
|
|
|
| Re: Debugging Shared Libraries [message #116954 is a reply to message #116904] |
Tue, 24 August 2004 11:34 |
| Eclipse User |
|
|
|
Ernesto,
It shouldn't make any difference what kind of project you use. I'm
certainly not disputing the experience you had, it's just that the two
systems (build and debugger) in the CDT do not have any
interdependencies that could effect the outcome of the debugging step.
It has to be a delta in the build flags. Did you build your project
differently when you switched over to standard?
Sean
Ernesto Bascón wrote:
> I had the same problem in my managed C++ project. I could not "step into" my
> methods implemented in DLLs.
>
> I changed to unmanaged C++ project and everything is working fine (I do not
> know exactly why :/)
>
> Regards
>
>
>
> Ernesto
>
>
> "dwa" <darndt@oriondevel.com> wrote in message
> news:cgegnv$lm8$1@eclipse.org...
>
>>I got a little farther. For some reason, CDT or Eclispe mangled the
>>makefile, so I fixed them manually and re-built. Now I can debug, but it
>>won't step into my DLL call. I tried going into disassembly and using F5
>>to step into the call, but it jumps over it.
>>
>>I also tried setting breakpoint in the DLL, but it doesn't stop there.
>>
>>Is this possible to do with CDT, or is the tool just not up to debugging
>>shared libs?
>>
>>-- Dave
>>
>>PS:
>>Ooops - I just tried going back in and adding Shared Libraries to the
>>debug configuration. Now I get an error "CDT can't debug" or something
>>like that. Good grief.
>>
>>I'm frustrated: Does anyone know a good g++/GNU IDE/debugger that I can
>>PAY for that actually works? I'll poney up the same as MS charges for
>>Visual Studio 7, if I can just find something that will actually WORK as
>>an IDE for g++. Sorry - but this is very disappointing.
>>
>>
>>
>
>
>
|
|
|
| Re: Debugging Shared Libraries [message #116959 is a reply to message #116904] |
Tue, 24 August 2004 11:45 |
| Eclipse User |
|
|
|
Ernesto,
I just did a quick test and I can step into a managed DLL too. I am
still interested in the delta between how your two projects were built,
if you still have that information.
Sean
Ernesto Bascón wrote:
> I had the same problem in my managed C++ project. I could not "step into" my
> methods implemented in DLLs.
>
> I changed to unmanaged C++ project and everything is working fine (I do not
> know exactly why :/)
>
> Regards
>
>
>
> Ernesto
>
>
> "dwa" <darndt@oriondevel.com> wrote in message
> news:cgegnv$lm8$1@eclipse.org...
>
>>I got a little farther. For some reason, CDT or Eclispe mangled the
>>makefile, so I fixed them manually and re-built. Now I can debug, but it
>>won't step into my DLL call. I tried going into disassembly and using F5
>>to step into the call, but it jumps over it.
>>
>>I also tried setting breakpoint in the DLL, but it doesn't stop there.
>>
>>Is this possible to do with CDT, or is the tool just not up to debugging
>>shared libs?
>>
>>-- Dave
>>
>>PS:
>>Ooops - I just tried going back in and adding Shared Libraries to the
>>debug configuration. Now I get an error "CDT can't debug" or something
>>like that. Good grief.
>>
>>I'm frustrated: Does anyone know a good g++/GNU IDE/debugger that I can
>>PAY for that actually works? I'll poney up the same as MS charges for
>>Visual Studio 7, if I can just find something that will actually WORK as
>>an IDE for g++. Sorry - but this is very disappointing.
>>
>>
>>
>
>
>
|
|
|
| Re: Debugging Shared Libraries [message #116972 is a reply to message #116942] |
Tue, 24 August 2004 12:37 |
| Eclipse User |
|
|
|
> Why don't we start with the simple case first,
> then work out from there.
>
> I use the latest stuff I downloaded from Cygwin:
> kernel: 1.5.10
> /usr/bin/g[cc|++]: 3.3.3
> /usr/bin/gdb: 2003-09-20-cvs
>
> I build the DLL source with the following arguments:
> g++ -O -g -DMAKEDLL -Wall -c -fmessage-length=0 -o $@ $<
>
> and the DLL/export lib with:
> g++ -shared -Wl,--out-implib=libmsgs.dll.a -Wl,--output-def=msgs.def -o
> $@ $^
>
> The main project includes the right header from the DLL project and gets
> built with USEDLL defined (the header has the following in it)
>
> #if defined(MAKEDLL)
> # define DLLEXPORT __declspec(dllexport)
> #elif defined(USEDLL)
> # define DLLEXPORT __declspec(dllimport)
> #else
> # define DLLEXPORT
> #endif
>
> It links in the library that is built (lib<name>.dll.a) and after the
> build I copy the cyg<name>.dll into the directory where the EXE is
located.
>
> From there, the only grief I get is when I try to step into methods in
> the system libraries (like trying to step into a call on basic_string).
>
> I realize that you are frustrated and you had hoped to find a commercial
> quality IDE, but before you give up all hope, let's at least eliminate
> the possiblity that some of your problems are relted to how the project
> is being built (or a missing intermediate step).
>
> Sean
>
Sean,
Thanks for your thoughtfull reply. When we set up our projects, we
allowed Eclipse/CDT to generate makefiles and used the command lines that
they laid down. I am seeing some differences in the command line arguments:
for example, we're using -g3 and -O0 (which I believe is the same as -O with
no level specified?), and the so's we generate are following the standard
lib*.a naming convention. Other than that, thing look pretty similar.
One thing that is different in your example is the use of # define
DLLEXPORT __declspec(dllexport/import). For simplicity (or laziness)
reasons, we opted not to use these symbols and allow everything to be
exported (I believe g++/gnu handles it this way to makes the Win32 shared
libs more like UNIX shared libs?).
My hunch is that this difference has something to do with it. I'll re-tool
a simple example and see if I can get it to work. I've also just now
downloaded and re-installed the latest Cygwin stuff, so we should be using
the same compiler/tools.
I'll follow-up with results.
-- Dave
ps:
Sorry for my rant last night. I'm not really expecting commercial grade -
but just something that provides the basics (and works). It's not as bad
as all that - it was just late. ;-)
|
|
|
| Re: Debugging Shared Libraries [message #116985 is a reply to message #116972] |
Tue, 24 August 2004 15:45 |
| Eclipse User |
|
|
|
Originally posted by: adam.n.gordon.saic.com
David et. al.-
I had the same type of problems w/ stepping in to the shared library in
the debugger (See my post from 30 JUL 2004). Basically, on the Debugger
Tab, there's a Shared Library tab. You'll need to select the Load
Shared Library Automatically option. Unfortunately, and this is a known
bug, you cannot save this option when you select it. Mucho annoying.
Hope this helps.
-Adam
David Arndt wrote:
>>Why don't we start with the simple case first,
>>then work out from there.
>>
>>I use the latest stuff I downloaded from Cygwin:
>>kernel: 1.5.10
>>/usr/bin/g[cc|++]: 3.3.3
>>/usr/bin/gdb: 2003-09-20-cvs
>>
>>I build the DLL source with the following arguments:
>>g++ -O -g -DMAKEDLL -Wall -c -fmessage-length=0 -o $@ $<
>>
>>and the DLL/export lib with:
>>g++ -shared -Wl,--out-implib=libmsgs.dll.a -Wl,--output-def=msgs.def -o
>>$@ $^
>>
>>The main project includes the right header from the DLL project and gets
>>built with USEDLL defined (the header has the following in it)
>>
>>#if defined(MAKEDLL)
>># define DLLEXPORT __declspec(dllexport)
>>#elif defined(USEDLL)
>># define DLLEXPORT __declspec(dllimport)
>>#else
>># define DLLEXPORT
>>#endif
>>
>>It links in the library that is built (lib<name>.dll.a) and after the
>>build I copy the cyg<name>.dll into the directory where the EXE is
>
> located.
>
>> From there, the only grief I get is when I try to step into methods in
>>the system libraries (like trying to step into a call on basic_string).
>>
>>I realize that you are frustrated and you had hoped to find a commercial
>>quality IDE, but before you give up all hope, let's at least eliminate
>>the possiblity that some of your problems are relted to how the project
>>is being built (or a missing intermediate step).
>>
>>Sean
>>
>
>
> Sean,
>
> Thanks for your thoughtfull reply. When we set up our projects, we
> allowed Eclipse/CDT to generate makefiles and used the command lines that
> they laid down. I am seeing some differences in the command line arguments:
> for example, we're using -g3 and -O0 (which I believe is the same as -O with
> no level specified?), and the so's we generate are following the standard
> lib*.a naming convention. Other than that, thing look pretty similar.
>
> One thing that is different in your example is the use of # define
> DLLEXPORT __declspec(dllexport/import). For simplicity (or laziness)
> reasons, we opted not to use these symbols and allow everything to be
> exported (I believe g++/gnu handles it this way to makes the Win32 shared
> libs more like UNIX shared libs?).
>
> My hunch is that this difference has something to do with it. I'll re-tool
> a simple example and see if I can get it to work. I've also just now
> downloaded and re-installed the latest Cygwin stuff, so we should be using
> the same compiler/tools.
>
> I'll follow-up with results.
>
> -- Dave
>
> ps:
> Sorry for my rant last night. I'm not really expecting commercial grade -
> but just something that provides the basics (and works). It's not as bad
> as all that - it was just late. ;-)
>
>
>
|
|
| | | | | | | |
| Re: Debugging Shared Libraries [message #117309 is a reply to message #117227] |
Wed, 25 August 2004 15:51 |
| Eclipse User |
|
|
|
Ernesto,
I'm relieved that you use the same flags, at least. The procedure to
build DLLs with Cygwin has morphed a couple of times (they used to have
a tool that created the dlls and export libraries/def files as part of
the build). Now they rely on the linker to produce the right ouput,
similar to what happens on *nix. That said, PE shared libraries do not
have the same sort of numbering convention that they use with ELF shared
libraries (i.e. it isn't possible to set the so number and register that
new version as *the* shared library to use). I am pretty sure that
Cygwin now looks for a *.dll at run time, and that your linker needs the
..a file at link time. According to the Cygwin site, the naming
convention is cyg<dll_name>.dll for the shared component,
lib<dll_name>.dll.a for the export component and that's what I output.
Sean
Ernesto Bascón wrote:
> It's very strange:
>
> My unmanaged makefile differs a lot from the managed makefile generated by
> CDT, but the compiler options are the same:
>
> -g3 -Wall -out-implib=mylib.lib -output-def=mylib.def
>
> Adam Gordon wrote at July, 29th about this problem:
>
> "Just an FYI to anyone else having the same problem. The problem was
> with my Makefile in building the shared library and executable. I have
> no idea what exactly it was, but I mucked with it enough and it worked.
>
> Assume I have MyTest.h, MyTest.cpp, and MyTestMain.cpp. I built the
> shared library with: "g++ -shared -Wall -g3 MyTest.cpp -o MyTest.so" (or
> MyTest.dll on windows) and I built the executable with:
> g++ -Wall -g3 -L. -lMyTest MyTestMain.cpp -o main-tester.exe
>
> Recall that ld on *nix looks, I think, for lib<libname>.so so you may
> have to specify the output file as libMyTest.so instead."
>
> I dunno if this can help, but it's obvious that a lot of people had the same
> problem.
>
> Saludos
>
>
> Ernesto
>
>
|
|
|
| Re: Debugging Shared Libraries [message #117423 is a reply to message #117190] |
Thu, 26 August 2004 05:00 |
| Eclipse User |
|
|
|
David Arndt wrote:
I'm also having much trouble with debugging DLLs. Is there a consensus on
what works? I can't get my proper projects to work at all, but have
managed to get limitted success with the following (I'm on Windows XP
using Cygwin) :
junk2.cpp
=========
const char* helloWorld() {
return "hello world";
}
junk.cpp
========
#include <iostream>
#include "junk2.hpp"
using namespace std;
const char* helloWorld();
int main(int argc, char* argv[]) {
cout << helloWorld() << endl;
}
Makefile
========
CXXFLAGS = -g
all : junk.dll junk.exe
@echo Done.
clean :
rm junk.o junk2.o junk.dll junk.exe
junk.exe : junk.o
g++ -g -o $@ $< -L./ -ljunk
junk.dll : junk2.o
g++ -g -shared -o $@ $<
With this I can step into main, but I can't step into the "helloWorld()"
function, or stop at a breakpoint in it. I've played with the debugger
launch options (which don't appear to save, or at least revert on
reopenning the options, so don't have any confidence that they are being
taken notice of), but can't get any results.
Much as I'd like to use eclipse for our project, I'm afraid that unless I
can get this to work I'm going to have to find another way....
> "Sean Evoy" <sevoy@ca.ibm.com> wrote in message
> news:cgfmnr$p56$1@eclipse.org...
> > David,
> >
> > The main project includes the right header from the DLL project and gets
> > built with USEDLL defined (the header has the following in it)
> >
> > #if defined(MAKEDLL)
> > # define DLLEXPORT __declspec(dllexport)
> > #elif defined(USEDLL)
> > # define DLLEXPORT __declspec(dllimport)
> > #else
> > # define DLLEXPORT
> > #endif
> >
> Sean, I've found that I can "get away" with only labelling
> __declspec(dllimport) and still be able to trace into the DLL. That is, I
> experimented by commenting out the __declspec(dllexport) on the build of the
> DLL and it doesn't seem to make any difference. My testing has shown that
> the __declspec(dllimport) is definately required, however. I haven't taken
> the time to inspect the assembly code to see what the difference are, but
> it's a notable point.
> Thanks,
> -- Dave
|
|
|
| Re: Debugging Shared Libraries [message #117548 is a reply to message #117309] |
Thu, 26 August 2004 10:40 |
| Eclipse User |
|
|
|
Originally posted by: ebascon.hotmail.com
Sean:
I am using mingw instead of Cygwin, so I think the problem is in other
place: Today I "discovered" that the problem nothing has to do with the
managed/unmanaged project.
I have the following class implemented in a DLL:
//no value definition for mingw
#define DLLEXPORT
class DLLEXPORT Base
{
public:
Base();
~Base();
};
From myTestApp.cpp I do:
int main()
{
Base* b = new Base();
...
delete b;
}
When I try to debug this, I cannot step into the "new Base();" (the
debugger just step out this), but, when the "delete b;" is reached, I can
step into and see my code!!!
Saludos
Ernesto
"Sean Evoy" <sevoy@ca.ibm.com> wrote in message
news:cgiqei$o4f$1@eclipse.org...
> Ernesto,
> I'm relieved that you use the same flags, at least. The procedure to
> build DLLs with Cygwin has morphed a couple of times (they used to have
> a tool that created the dlls and export libraries/def files as part of
> the build). Now they rely on the linker to produce the right ouput,
> similar to what happens on *nix. That said, PE shared libraries do not
> have the same sort of numbering convention that they use with ELF shared
> libraries (i.e. it isn't possible to set the so number and register that
> new version as *the* shared library to use). I am pretty sure that
> Cygwin now looks for a *.dll at run time, and that your linker needs the
> .a file at link time. According to the Cygwin site, the naming
> convention is cyg<dll_name>.dll for the shared component,
> lib<dll_name>.dll.a for the export component and that's what I output.
>
> Sean
>
> Ernesto Basc
|
|
|
| Re: Debugging Shared Libraries [message #117560 is a reply to message #117423] |
Thu, 26 August 2004 12:46 |
| Eclipse User |
|
|
|
"Tom Quarendon" <tomq@teamwpc.co.uk> wrote in message
news:cgk8rs$pud$1@eclipse.org...
> I'm also having much trouble with debugging DLLs. Is there a consensus on
> what works? I can't get my proper projects to work at all, but have
> managed to get limitted success with the following (I'm on Windows XP
> using Cygwin) :
>
> junk2.cpp
> =========
> const char* helloWorld() {
> return "hello world";
> }
>
> junk.cpp
> ========
> #include <iostream>
> #include "junk2.hpp"
>
> using namespace std;
>
> const char* helloWorld();
>
> int main(int argc, char* argv[]) {
> cout << helloWorld() << endl;
> }
> .....
>
> With this I can step into main, but I can't step into the "helloWorld()"
> function, or stop at a breakpoint in it. I've played with the debugger
> launch options (which don't appear to save, or at least revert on
> reopenning the options, so don't have any confidence that they are being
> taken notice of), but can't get any results.
>
Tom,
1) Try your the declaration you use to:
__declspec(dllimport) const char* helloWorld();
int main(int argc, char* argv[]) {
cout << helloWorld() << endl;
}
2) Then, be sure you're using the "straight up gdb" debugger, instead of the
Cygwin gdb debugger
3) Go to the Debug/Debugger/Shared Libraries tab and make sure you select
the option to automatically load shared libraries.
This combination of steps seemed to do the trick for me.
-- Dave
PS:
Once again, usually, if you're using __declspec(dllimport) from the caller,
it is assumed you also need to put a __declspec(dllexport) on the exported
function in your DLL, but I've found that with g++ it seems to generate as a
dllexport by default, even if I leave this off in the compilation of the
..cpp code in the DLL.
|
|
|
| Re: Debugging Shared Libraries [message #117660 is a reply to message #117560] |
Fri, 27 August 2004 02:43 |
| Eclipse User |
|
|
|
Right thanks.
So although I don't need the __declspec to make the code compile link and
run, I do need it to be able to debug the result? Thats odd.
By the way, normally I make my DLLs with matching export files to link
against, by using the --export-all-symbols option. I'm I need to use the
__declspec declarations in order to make the debugger happy, how do I link
my DLL and create an export file containing only those symbols which are
__declspec(dllexport)'ed? Currently I link my DLL with
%.dll : ${OBJS}
g++ -g -o $@ -shared \
${LIBDIRS} \
-Wl,--out-implib=lib$*.a \
-Wl,--export-all-symbols \
-Wl,--enable-auto-import \
-Wl,--whole-archive ${OBJS} \
-Wl,--no-whole-archive $(LIBS)
as per the instructions on the Cygwin website on building DLLs, because
this is the only doco I've ben able to find.
David Arndt wrote:
> "Tom Quarendon" <tomq@teamwpc.co.uk> wrote in message
> news:cgk8rs$pud$1@eclipse.org...
> > I'm also having much trouble with debugging DLLs. Is there a consensus on
> > what works? I can't get my proper projects to work at all, but have
> > managed to get limitted success with the following (I'm on Windows XP
> > using Cygwin) :
> >
> > junk2.cpp
> > =========
> > const char* helloWorld() {
> > return "hello world";
> > }
> >
> > junk.cpp
> > ========
> > #include <iostream>
> > #include "junk2.hpp"
> >
> > using namespace std;
> >
> > const char* helloWorld();
> >
> > int main(int argc, char* argv[]) {
> > cout << helloWorld() << endl;
> > }
> > .....
> >
> > With this I can step into main, but I can't step into the "helloWorld()"
> > function, or stop at a breakpoint in it. I've played with the debugger
> > launch options (which don't appear to save, or at least revert on
> > reopenning the options, so don't have any confidence that they are being
> > taken notice of), but can't get any results.
> >
> Tom,
> 1) Try your the declaration you use to:
> __declspec(dllimport) const char* helloWorld();
> int main(int argc, char* argv[]) {
> cout << helloWorld() << endl;
> }
> 2) Then, be sure you're using the "straight up gdb" debugger, instead of the
> Cygwin gdb debugger
> 3) Go to the Debug/Debugger/Shared Libraries tab and make sure you select
> the option to automatically load shared libraries.
> This combination of steps seemed to do the trick for me.
> -- Dave
> PS:
> Once again, usually, if you're using __declspec(dllimport) from the caller,
> it is assumed you also need to put a __declspec(dllexport) on the exported
> function in your DLL, but I've found that with g++ it seems to generate as a
> dllexport by default, even if I leave this off in the compilation of the
> ..cpp code in the DLL.
|
|
| |
| Re: Debugging Shared Libraries [message #117859 is a reply to message #116942] |
Fri, 27 August 2004 15:56 |
| Eclipse User |
|
|
|
Originally posted by: simon.ou.edu
Hi Sean...
I appreciate your explanation here. What you explained here was what I
needed as well.
In the spirit of enlightenment, I wonder if you could explain or point
toward some resources that may explain the meaning of:
-fmessage-length=0
--out-implib=libmsgs.dll.a
--output-def=msgs.def
I suppose that 'msgs' is the name of your output binary, and that the
linking flag would include
-l msgs.dll
as per the above flags. Would this be correct?
I appreciate the managed-make projects since some engineers do not have
much time to learn about makefiles and all the associated options and
such. Managed make files save a lot of time.
Thanks.
Regards...
Miguel.
Sean Evoy wrote:
> David,
> I do not have anywhere near as much trouble as you are reporting.
> Granted, I am using a simple example right now, but I build a DLL as a
> standard project, link it into a managed C++ project, and I can step
> into the DLL no trouble. Why don't we start with the simple case first,
> then work out from there.
>
> I use the latest stuff I downloaded from Cygwin:
> kernel: 1.5.10
> /usr/bin/g[cc|++]: 3.3.3
> /usr/bin/gdb: 2003-09-20-cvs
>
> I build the DLL source with the following arguments:
> g++ -O -g -DMAKEDLL -Wall -c -fmessage-length=0 -o $@ $<
>
> and the DLL/export lib with:
> g++ -shared -Wl,--out-implib=libmsgs.dll.a -Wl,--output-def=msgs.def -o
> $@ $^
>
> The main project includes the right header from the DLL project and gets
> built with USEDLL defined (the header has the following in it)
>
> #if defined(MAKEDLL)
> # define DLLEXPORT __declspec(dllexport)
> #elif defined(USEDLL)
> # define DLLEXPORT __declspec(dllimport)
> #else
> # define DLLEXPORT
> #endif
>
> It links in the library that is built (lib<name>.dll.a) and after the
> build I copy the cyg<name>.dll into the directory where the EXE is located.
>
> From there, the only grief I get is when I try to step into methods in
> the system libraries (like trying to step into a call on basic_string).
>
> I realize that you are frustrated and you had hoped to find a commercial
> quality IDE, but before you give up all hope, let's at least eliminate
> the possiblity that some of your problems are relted to how the project
> is being built (or a missing intermediate step).
>
> Sean
>
> dwa wrote:
>
>> I'm having an impossible time trying to debug a simple hello world
>> application that gets it's "hello world" string from a shared library.
>> Here are the symptoms of the patients illness:
>>
>> 1. If I create JUST a main and link with no shared libraries, I can
>> launch
>> the debugger, set breakpoints, etc. (I'm running g++ on Cygwin under
>> Win32).
>>
>> 2. If a link with ANY shared library, when I launch the debugger through
>> Eclipse, I get the "Run in Background" dialog and it just sites there
>> forever while the little blue progress thing flashes in the lower right
>> corner.
>>
>> 3. On numerous occasions, the entire IDE just ABENDS (faults and
>> disapears
>> completely) if I attempt debugging when linked with a shared lib.
>>
>> The workspace contains two projects: a main, created as an "Executable -
>> Cygwin" and another shared library project, that I created as a "GNU
>> Shared DLL".
>> The program RUNS fine when linked with the DLL - but how does one debug
>> when linked with a shared lib?
>>
>> -- Dave
>>
>>
>>
>>
|
|
|
| Re: Debugging Shared Libraries [message #117885 is a reply to message #117859] |
Fri, 27 August 2004 17:00 |
| Eclipse User |
|
|
|
Miguel,
The -fmessages-length=0 tells the C++ front-end to format the error
messages to output on a single line (i.e. don't break long messages over
multiple lines at any particular boundary). I am pretty sure this only
applies to g++ for the moment, but I'm leaving it in the gcc args in
hopes that someday it'll be there. Anyway, it is Gnu specific, deals
with error output formatting and has nothing to do with generating
debugging info in the DLL.
The --out-implib argument tells the linker to create an import library
that must be linked into the executable (or other DLLs) using the DLL at
link time. The naming convention is probably the diciest part; the
'lib' prefix and 'a' extension are a given for a library, but the Cygwin
site recommends the '.dll.' as well, so that's what I do. It's probably
not necessary but ....
The def file just defines what functions and variable are exported from
the DLL. You can create this file by hand, or have the linker do it via
the argument --output-def. It's just a text file, so you can open it up
and see what the compiler puts there.
People familiar with the *nix way of doing shared libraries tend to
shudder at all of this, but this is the way that all shared libraries
are created on Win32 platforms. When I created the shared library build
targets, I just asked "how would I do it without CDT" and implemented it
that way.
All the best,
Sean
Miguel Simon wrote:
> Hi Sean...
>
> I appreciate your explanation here. What you explained here was what I
> needed as well.
>
> In the spirit of enlightenment, I wonder if you could explain or point
> toward some resources that may explain the meaning of:
>
> -fmessage-length=0
> --out-implib=libmsgs.dll.a
> --output-def=msgs.def
>
> I suppose that 'msgs' is the name of your output binary, and that the
> linking flag would include
>
> -l msgs.dll
>
> as per the above flags. Would this be correct?
>
> I appreciate the managed-make projects since some engineers do not have
> much time to learn about makefiles and all the associated options and
> such. Managed make files save a lot of time.
>
> Thanks.
>
> Regards...
>
> Miguel.
>
>
>
> Sean Evoy wrote:
>
>> David,
>> I do not have anywhere near as much trouble as you are reporting.
>> Granted, I am using a simple example right now, but I build a DLL as a
>> standard project, link it into a managed C++ project, and I can step
>> into the DLL no trouble. Why don't we start with the simple case
>> first, then work out from there.
>>
>> I use the latest stuff I downloaded from Cygwin:
>> kernel: 1.5.10
>> /usr/bin/g[cc|++]: 3.3.3
>> /usr/bin/gdb: 2003-09-20-cvs
>>
>> I build the DLL source with the following arguments:
>> g++ -O -g -DMAKEDLL -Wall -c -fmessage-length=0 -o $@ $<
>>
>> and the DLL/export lib with:
>> g++ -shared -Wl,--out-implib=libmsgs.dll.a -Wl,--output-def=msgs.def
>> -o $@ $^
>>
>> The main project includes the right header from the DLL project and
>> gets built with USEDLL defined (the header has the following in it)
>>
>> #if defined(MAKEDLL)
>> # define DLLEXPORT __declspec(dllexport)
>> #elif defined(USEDLL)
>> # define DLLEXPORT __declspec(dllimport)
>> #else
>> # define DLLEXPORT
>> #endif
>>
>> It links in the library that is built (lib<name>.dll.a) and after the
>> build I copy the cyg<name>.dll into the directory where the EXE is
>> located.
>>
>> From there, the only grief I get is when I try to step into methods
>> in the system libraries (like trying to step into a call on
>> basic_string).
>>
>> I realize that you are frustrated and you had hoped to find a
>> commercial quality IDE, but before you give up all hope, let's at
>> least eliminate the possiblity that some of your problems are relted
>> to how the project is being built (or a missing intermediate step).
>>
>> Sean
>>
>> dwa wrote:
>>
>>> I'm having an impossible time trying to debug a simple hello world
>>> application that gets it's "hello world" string from a shared
>>> library. Here are the symptoms of the patients illness:
>>>
>>> 1. If I create JUST a main and link with no shared libraries, I can
>>> launch
>>> the debugger, set breakpoints, etc. (I'm running g++ on Cygwin under
>>> Win32).
>>>
>>> 2. If a link with ANY shared library, when I launch the debugger through
>>> Eclipse, I get the "Run in Background" dialog and it just sites there
>>> forever while the little blue progress thing flashes in the lower right
>>> corner.
>>>
>>> 3. On numerous occasions, the entire IDE just ABENDS (faults and
>>> disapears
>>> completely) if I attempt debugging when linked with a shared lib.
>>>
>>> The workspace contains two projects: a main, created as an "Executable -
>>> Cygwin" and another shared library project, that I created as a "GNU
>>> Shared DLL". The program RUNS fine when linked with the DLL - but how
>>> does one debug
>>> when linked with a shared lib?
>>>
>>> -- Dave
>>>
>>>
>>>
>>>
>
|
|
|
Goto Forum:
Current Time: Fri Jul 18 08:45:31 EDT 2025
Powered by FUDForum. Page generated in 0.65532 seconds |
Home