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] |
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] |