| Message ID | bfbfdaaea8592dd87f96.1362244746@suse64 |
|---|---|
| State | Rejected |
| Headers | show |
Trevor, All, On Saturday 02 March 2013 Trevor Woerner wrote: > # HG changeset patch > # User Trevor Woerner <twoerner@gmail.com> > # Date 1362239822 18000 > # Node ID bfbfdaaea8592dd87f96ddea8637f5b17b194ad4 > # Parent f89f8e6f876679184acb66ea642e42c9e7cf2f44 > debug/gdb: include expat for gdb-cross > > Some boards, such as the ST Discovery, have a debugger interface which > can be queried for a device feature description which is provided in XML. > Therefore it would be nice to have expat available to make use of this > information. > > Signed-off-by: Trevor Woerner <twoerner@gmail.com> > > diff -r f89f8e6f8766 -r bfbfdaaea859 scripts/build/debug/300-gdb.sh > --- a/scripts/build/debug/300-gdb.sh Mon Feb 25 21:19:31 2013 +0100 > +++ b/scripts/build/debug/300-gdb.sh Sat Mar 02 10:57:02 2013 -0500 > @@ -16,6 +16,7 @@ > > if [ "${CT_GDB_CROSS}" = y ]; then > do_gdb=y > + do_expat=y > fi This is wrong: - 'do_expat' is used to detect whether the expat lib shall be downloaded and extracted; - 'do_expat' is then mis-used: - it is never used to build expat for the host, but is used to decide whether to enable/disable expat in the cross-gdb - it is used to decide whether to build expat for the target, but is always set when the native-gdb is selected, so the check is pointless. What should be done is: - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses') - use 'need_expat' only to decide whether to download/extract libexpat - cross-gdb: always enable expat support - native-gdb: ditto I'm on it. Thanks for the report! :-) Regards, Yann E. MORIN.
Hi Yann, Thanks for looking into this. On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > This is wrong: > - 'do_expat' is used to detect whether the expat lib shall be downloaded > and extracted; > - 'do_expat' is then mis-used: > - it is never used to build expat for the host, but is used to decide > whether to enable/disable expat in the cross-gdb > - it is used to decide whether to build expat for the target, but is > always set when the native-gdb is selected, so the check is pointless. So if I understand you correctly, the only thing the build needs to determine is if expat needs to be included in the sysroot? > What should be done is: > - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses') > - use 'need_expat' only to decide whether to download/extract libexpat > - cross-gdb: always enable expat support > - native-gdb: ditto In other words, if the build doesn't interfere with gdb's ./configure, gdb's ./configure will naturally look for and link in the host's expat? Best regards, Trevor -- For unsubscribe information see http://sourceware.org/lists.html#faq
Trevor, All, On Sunday 03 March 2013 Trevor Woerner wrote: > On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > This is wrong: > > - 'do_expat' is used to detect whether the expat lib shall be downloaded > > and extracted; > > - 'do_expat' is then mis-used: > > - it is never used to build expat for the host, but is used to decide > > whether to enable/disable expat in the cross-gdb > > - it is used to decide whether to build expat for the target, but is > > always set when the native-gdb is selected, so the check is pointless. > > So if I understand you correctly, the only thing the build needs to > determine is if expat needs to be included in the sysroot? Sorta. Crosstool-NG only builds a static version of libexpat, and never installs it in the sysroot (ditto ncurses). So, we only need to know whether we need to build expat (ncurses) for the target, and point gdb's configure to the place we installed it. The reason for not installing expat/ncurses in the sysroot is that the libs are not part of the toolchain. They are only used for internal components, and should not be exposed in the sysroot, in case the user wants another version, or different compile flags, or a patched version. This is purely internal to crosstool-NG. > > What should be done is: > > - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses') > > - use 'need_expat' only to decide whether to download/extract libexpat > > - cross-gdb: always enable expat support > > - native-gdb: ditto > > In other words, if the build doesn't interfere with gdb's ./configure, > gdb's ./configure will naturally look for and link in the host's > expat? Almost, as we still need to tell the native-gdb's ./configure where to find our internally built target expat/ncurses. But for the cross-gdb, it should automatically find the host's libs, indeed, so you still need to install the devel packages on your host. Regards, Yann E. MORIN.
I am confused. Speaking as a crosstool / cross-gdb end-user, what does this mean wanting to deploy code to and consequently debug code on target? On Sun, Mar 3, 2013 at 8:58 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > Trevor, All, > > On Sunday 03 March 2013 Trevor Woerner wrote: >> On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: >> > This is wrong: >> > - 'do_expat' is used to detect whether the expat lib shall be downloaded >> > and extracted; >> > - 'do_expat' is then mis-used: >> > - it is never used to build expat for the host, but is used to decide >> > whether to enable/disable expat in the cross-gdb >> > - it is used to decide whether to build expat for the target, but is >> > always set when the native-gdb is selected, so the check is pointless. >> >> So if I understand you correctly, the only thing the build needs to >> determine is if expat needs to be included in the sysroot? > > Sorta. Crosstool-NG only builds a static version of libexpat, and never > installs it in the sysroot (ditto ncurses). > > So, we only need to know whether we need to build expat (ncurses) for the > target, and point gdb's configure to the place we installed it. > > The reason for not installing expat/ncurses in the sysroot is that the > libs are not part of the toolchain. They are only used for internal > components, and should not be exposed in the sysroot, in case the user > wants another version, or different compile flags, or a patched version. > > This is purely internal to crosstool-NG. > >> > What should be done is: >> > - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses') >> > - use 'need_expat' only to decide whether to download/extract libexpat >> > - cross-gdb: always enable expat support >> > - native-gdb: ditto >> >> In other words, if the build doesn't interfere with gdb's ./configure, >> gdb's ./configure will naturally look for and link in the host's >> expat? > > Almost, as we still need to tell the native-gdb's ./configure where to > find our internally built target expat/ncurses. > > But for the cross-gdb, it should automatically find the host's libs, > indeed, so you still need to install the devel packages on your host. > > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------' > > -- > For unsubscribe information see http://sourceware.org/lists.html#faq > -- For unsubscribe information see http://sourceware.org/lists.html#faq
Michael, All, Please, do *not* top-post. It makes it difficult to see what part of the original message confuses you. On Sunday 03 March 2013 Michael Powell wrote: > On Sun, Mar 3, 2013 at 8:58 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > On Sunday 03 March 2013 Trevor Woerner wrote: > >> On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > >> > This is wrong: > >> > - 'do_expat' is used to detect whether the expat lib shall be downloaded > >> > and extracted; > >> > - 'do_expat' is then mis-used: > >> > - it is never used to build expat for the host, but is used to decide > >> > whether to enable/disable expat in the cross-gdb > >> > - it is used to decide whether to build expat for the target, but is > >> > always set when the native-gdb is selected, so the check is pointless. > >> > >> So if I understand you correctly, the only thing the build needs to > >> determine is if expat needs to be included in the sysroot? > > > > Sorta. Crosstool-NG only builds a static version of libexpat, and never > > installs it in the sysroot (ditto ncurses). > > > > So, we only need to know whether we need to build expat (ncurses) for the > > target, and point gdb's configure to the place we installed it. > > > > The reason for not installing expat/ncurses in the sysroot is that the > > libs are not part of the toolchain. They are only used for internal > > components, and should not be exposed in the sysroot, in case the user > > wants another version, or different compile flags, or a patched version. > > > > This is purely internal to crosstool-NG. > > > >> > What should be done is: > >> > - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses') > >> > - use 'need_expat' only to decide whether to download/extract libexpat > >> > - cross-gdb: always enable expat support > >> > - native-gdb: ditto > >> > >> In other words, if the build doesn't interfere with gdb's ./configure, > >> gdb's ./configure will naturally look for and link in the host's > >> expat? > > > > Almost, as we still need to tell the native-gdb's ./configure where to > > find our internally built target expat/ncurses. > > > > But for the cross-gdb, it should automatically find the host's libs, > > indeed, so you still need to install the devel packages on your host. > I am confused. Speaking as a crosstool / cross-gdb end-user, what does > this mean wanting to deploy code to and consequently debug code on > target? Nothing at all from an end-user perspective: the cross-gdb and the native-gdb will both have expat support. The expat version built by crosstool-NG is not exposed in the sysroot on purpose, as it's not part of the toolchain: it's only needed to be able to build the native-gdb, so we build a static version that we properly hide away by not installing it in the sysroot. The same goes for ncurses. If you need expat or ncurses for your apps, you'll have to compile them. Regards, Yann E. MORIN.
diff -r f89f8e6f8766 -r bfbfdaaea859 scripts/build/debug/300-gdb.sh --- a/scripts/build/debug/300-gdb.sh Mon Feb 25 21:19:31 2013 +0100 +++ b/scripts/build/debug/300-gdb.sh Sat Mar 02 10:57:02 2013 -0500 @@ -16,6 +16,7 @@ if [ "${CT_GDB_CROSS}" = y ]; then do_gdb=y + do_expat=y fi if [ "${CT_GDB_GDBSERVER}" = "y" ]; then
# HG changeset patch # User Trevor Woerner <twoerner@gmail.com> # Date 1362239822 18000 # Node ID bfbfdaaea8592dd87f96ddea8637f5b17b194ad4 # Parent f89f8e6f876679184acb66ea642e42c9e7cf2f44 debug/gdb: include expat for gdb-cross Some boards, such as the ST Discovery, have a debugger interface which can be queried for a device feature description which is provided in XML. Therefore it would be nice to have expat available to make use of this information. Signed-off-by: Trevor Woerner <twoerner@gmail.com> -- For unsubscribe information see http://sourceware.org/lists.html#faq