This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: debug-problem with cygwin-linux-cross


Hi !

Thank you for your fast reply Dan..

> > I compiled a cross toolchain with crosstools 0.38 (thx Dan !)
> > - gcc 3.3.3
> > - glibc 3.2.3
> > - binutils 2.15
> > - host&build: i686-cygwin-linux
> > - target : i386-linux-gnu
> > Under WinXP with cygwin an it runs without problems.
> >
> > After the compilation I was a little confused about the output path
> > structure
> > (C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-
> gnu\i386-unknown-linux-gnu\bin -> contained the tools from cygwin
> >
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\bin
> -> contained the new toolchain
> > C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-
> gnu\include
> > was nearly empty but some includefiles where needed so I copied them
to
> > C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-
> gnu\i386-unknown-linux-gnu\inlcude
> > and so on...)
> 
> You shouldn't need to do that... what happens if you don't?

Okay, I try to explain that.
After compilation, there are two include paths in the result path:

(1)
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\inc
lude

(2)
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\i38
6-unknown-linux-gnu\include

And (1) is nearly empty, except of other paths:
(1)\c++\3.3.3\i386-unknown-linux-gnu\bits
(1)\c++\3.3.3\bits
(1)\c++\3.3.3\backward
(1)\c++\3.3.3\ext
Each of them contain a few headers, for example (1)\c++\3.3.3\ contain
iostream

So if I want to include C++ Standard headers, such as iostream, I have
to put all the files in these paths in the same /include directory,
because if I don't the references on the headers do not work (iostream
includes other headers which are only in (2) and so on)

The same problem is for libraries...

For me there is a understanding problem why the result path structure is
so fragmented. 
In (2)/../bin there are my binaries of the result toolchain
(i386-unknown-linux-gnu-g++.exe) and 
In (1)/../bin there are also binaries, but with the old tools (gcc.exe)

I tried to recompile the toolchain, but there is the same result.
Each of the two paths contain the paths of the other, but
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu
Is nearly empty (not much files) and
C:\cygwin\opt\crosstool\gcc-3.3.3-glibc-2.3.2\i386-unknown-linux-gnu\i38
6-unknown-linux-gnu
contains most of the results...

Do you know what is going wrong here ?
 
> > If I want to debug my application with gdbserver on the target and
gdb
> > 6.0 on my cygwin host I get several errors:
> >
------------------------------------------------------------------------
> > ----
> > warning: Unable to find dynamic linker breakpoint function.
> > GDB will be unable to debug shared library initializers
> > and track explicitly loaded dynamic code.
> > Error while mapping shared library sections:
> > /lib/libstdc++.so.5: No such file or directory.  ...
> > Error while reading shared library symbols:
> > Stopped due to shared library event
> > /lib/ld-linux.so.2: No such file or directory.
> > Reply contains invalid hex digit 78 ...
> >
> > Seems that it can not find those libs although they are present (and
I
> > added the path to them to the linker options)
> > I tried to copy them around, for example to cygwin/usr/lib, but this
> > doesn't help.
> > If I do : i386-unknown-linux-gnu-ld --verbose | grep SEARCH
> > The answer is: SEARCH_DIR("=usr/local/lib"); SEARCH_DIOR("=/lib");
> > SEARCH_DIOR("=usr/lib")
> 
> Did you read
>   http://www.kegel.com/linux/gdbserver.html
> ?

Yes i read that, but sadly it did not help. 
I found some hints that the not-finding of the libraries could be a
linker-problem so I think I should verifiy that my toolchain is correct
at first, before I can surely say that it is a gdb-error...
Giving the new /lib path to the gdb-options did not help in this case
(by the way: I use eclipse as a frontend for my debug session).

> > Although I can step-trough my program at termination of it, gdb
always
> > return the "Reply contains invalid hex digit 78" and aborts.
> 
> Now *there's* a question you need to take to the gdb mailing list...
> - Dan

I already had this problem under linux during remote-debugging the
target and solved it by using exactly that gdb 6.0 instead of gdb 6.1. -
so I tried to compile it for cygwin and I think there must be a
connection between my cross-compiled gdb and this error (of course it is
;) but maybe youre right and I should post this to the gdb-mailingslist)


One thing last: while browsing through the web I always got links to the
CrossGCC-FAQ (also in singnatures of this mailinglist) but I never find
them - because all I got is a redirection to billgatliff.com, but there
are no FAQs on this site.... (there is nothing about cross-gcc on this
site).. or am I just blind.. !?

thanks in advance

Thomas


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]