[CT-NG 1.11.3] Cross-gdb XML support missing

[CT-NG 1.11.3] Cross-gdb XML support missing

[Benoît THÉBAUDEAU]

Hi Yann, all,

If I build Linaro GDB as a crosstool with CT-NG 1.11.3, I get the following
warning when I run GDB:
"Can not parse XML target description; XML support was disabled at compile time"

This may also cause errors when accessing target registers.

I think that we should do something like the patch below to fix this (not yet
tested).

By the way, note that Linaro GCC 4.5/4.6 and GDB can now be bumped to revision
2011.05.

Best regards,
Benoît
--------------------------------------------------------------------------------
This patch adds XML support to cross-gdb so that the target description can be
parsed. This avoids possible runtime errors and the following GDB warning:
"Can not parse XML target description; XML support was disabled at compile time"

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
---
--- a/scripts/build/debug/300-gdb.sh	Sat May 21 14:45:04 2011
+++ b/scripts/build/debug/300-gdb.sh	Sat May 21 15:08:56 2011
@@ -16,6 +16,7 @@

     if [ "${CT_GDB_CROSS}" = y ]; then
         do_gdb=y
+        do_expat=y
     fi

     if [ "${CT_GDB_GDBSERVER}" = "y" ]; then
@@ -100,8 +101,34 @@

     if [ "${CT_GDB_CROSS}" = "y" ]; then
         local -a cross_extra_config
+        local -a gdb_cross_CFLAGS

         CT_DoStep INFO "Installing cross-gdb"
+
+        if [ "${do_expat}" = "y" ]; then
+            CT_DoLog EXTRA "Building static host expat"
+
+            mkdir -p "${CT_BUILD_DIR}/host-expat-build"
+            cd "${CT_BUILD_DIR}/host-expat-build"
+
+            CT_DoExecLog CFG                                                \
+            "${CT_SRC_DIR}/expat-${CT_DEBUG_GDB_EXPAT_VERSION}/configure"   \
+                --build=${CT_BUILD}                                         \
+                --host=${CT_HOST}                                           \
+                --prefix="${CT_BUILD_DIR}/static-host"                      \
+                --enable-static                                             \
+                --disable-shared
+
+            CT_DoExecLog ALL make ${JOBSFLAGS}
+            CT_DoExecLog ALL make install
+
+            cross_extra_config+=("--with-expat")
+            cross_extra_config+=("--with-libexpat-prefix=${CT_BUILD_DIR}/static-host")
+            # There's no better way to tell gdb where to find -lexpat... :-(
+            gdb_cross_CFLAGS+=("-I${CT_BUILD_DIR}/static-host/include")
+            gdb_cross_CFLAGS+=("-L${CT_BUILD_DIR}/static-host/lib")
+        fi # do_expat
+
         CT_DoLog EXTRA "Configuring cross-gdb"

         mkdir -p "${CT_BUILD_DIR}/build-gdb-cross"
@@ -127,6 +154,7 @@
         CT_DoExecLog CFG                                \
         CC="${CC_for_gdb}"                              \
         LD="${LD_for_gdb}"                              \
+        CFLAGS="${gdb_cross_CFLAGS[*]}"                 \
         "${gdb_cross_configure}"                        \
             --build=${CT_BUILD}                         \
             --host=${CT_HOST}                           \

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH 1 of 2] cross-gdb: add XML support

[Benoît THÉBAUDEAU]

# HG changeset patch
# User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
# Date 1306235318 -7200
# Node ID 420687b63c9775201e84e40f76b4c176996e3bda
# Parent  230d50dd23230a2b09fb390d771f5628a1c7342f
cross-gdb: add XML support

This patch adds XML support to cross-gdb so that the target description can be
parsed. This avoids possible runtime malfunctions, and the following GDB warning:
"Can not parse XML target description; XML support was disabled at compile time"

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
--- a/scripts/build/debug/300-gdb.sh
+++ b/scripts/build/debug/300-gdb.sh
@@ -16,6 +16,7 @@
 
     if [ "${CT_GDB_CROSS}" = y ]; then
         do_gdb=y
+        do_expat=y
     fi
 
     if [ "${CT_GDB_GDBSERVER}" = "y" ]; then
@@ -100,8 +101,34 @@
 
     if [ "${CT_GDB_CROSS}" = "y" ]; then
         local -a cross_extra_config
+        local -a gdb_cross_CFLAGS
 
         CT_DoStep INFO "Installing cross-gdb"
+
+        if [ "${do_expat}" = "y" ]; then
+            CT_DoLog EXTRA "Building static host expat"
+
+            mkdir -p "${CT_BUILD_DIR}/host-expat-build"
+            cd "${CT_BUILD_DIR}/host-expat-build"
+
+            CT_DoExecLog CFG                                                \
+            "${CT_SRC_DIR}/expat-${CT_DEBUG_GDB_EXPAT_VERSION}/configure"   \
+                --build=${CT_BUILD}                                         \
+                --host=${CT_HOST}                                           \
+                --prefix="${CT_BUILD_DIR}/static-host"                      \
+                --enable-static                                             \
+                --disable-shared
+
+            CT_DoExecLog ALL make ${JOBSFLAGS}
+            CT_DoExecLog ALL make install
+
+            cross_extra_config+=("--with-expat")
+            cross_extra_config+=("--with-libexpat-prefix=${CT_BUILD_DIR}/static-host")
+            # There's no better way to tell gdb where to find -lexpat... :-(
+            gdb_cross_CFLAGS+=("-I${CT_BUILD_DIR}/static-host/include")
+            gdb_cross_CFLAGS+=("-L${CT_BUILD_DIR}/static-host/lib")
+        fi # do_expat
+
         CT_DoLog EXTRA "Configuring cross-gdb"
 
         mkdir -p "${CT_BUILD_DIR}/build-gdb-cross"
@@ -127,6 +154,7 @@
         CT_DoExecLog CFG                                \
         CC="${CC_for_gdb}"                              \
         LD="${LD_for_gdb}"                              \
+        CFLAGS="${gdb_cross_CFLAGS[*]}"                 \
         "${gdb_cross_configure}"                        \
             --build=${CT_BUILD}                         \
             --host=${CT_HOST}                           \

[PATCH 0 of 2] cross-gdb: fix runtime warnings

[Benoît THÉBAUDEAU]

Hi Yann, all!

The following patchset fixes two cross-gdb runtime warnings that can lead to
malfunctions.

I have tested it and it works.

Best regards,
Benoît

[PATCH 2 of 2] cross-gdb: fix runtime sysroot

[Benoît THÉBAUDEAU]

# HG changeset patch
# User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
# Date 1306235541 -7200
# Node ID 6f6493d05f127328c6168f0a381dbc1080f070c2
# Parent  420687b63c9775201e84e40f76b4c176996e3bda
cross-gdb: fix runtime sysroot

This patch sets the runtime sysroot to fix the following GDB warning:
"Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code."

The sysroot can later be changed within gdb with the `set sysroot`
command if necessary.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
--- a/scripts/build/debug/300-gdb.sh
+++ b/scripts/build/debug/300-gdb.sh
@@ -161,6 +161,7 @@
             --target=${CT_TARGET}                       \
             --prefix="${CT_PREFIX_DIR}"                 \
             --with-build-sysroot="${CT_SYSROOT_DIR}"    \
+            --with-sysroot="${CT_SYSROOT_DIR}"          \
             --disable-werror                            \
             "${cross_extra_config[@]}"
 

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Yann E. MORIN]

Benoit, All,

On Tuesday 24 May 2011 13:20:45 Benoît THÉBAUDEAU wrote:
> # HG changeset patch
> # User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> # Date 1306235318 -7200
> # Node ID 420687b63c9775201e84e40f76b4c176996e3bda
> # Parent  230d50dd23230a2b09fb390d771f5628a1c7342f
> cross-gdb: add XML support
> 
> This patch adds XML support to cross-gdb so that the target description can be
> parsed. This avoids possible runtime malfunctions, and the following GDB warning:
> "Can not parse XML target description; XML support was disabled at compile time"

I am not too fond of this patch for two reasons:

1) libexpat should be provided by the host:
   - in case of cross-compilation, it should be installed on your distro.
     If you want a static gdb, then also install the -dev package from your
     distro;
   - in case of canadian-cross, your upper-layer build-system should install
     libexpat itself.

  Note that the companion libraries are a bit special, as, until recently,
  distros were not shipping them, or were shipping out-dated versions. This
  is not the case for libexpat.

2) code duplication to build libexpat
   - at least, provide a function that build libexpat, and takes as
     arguments: prefix, build and host
   - better yet, include it in the companion libraries infrastructure,
     even if there is no option and no version selection.

But again, I am not really inclined to accept such a change, as explained
above...

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

Re: [PATCH 2 of 2] cross-gdb: fix runtime sysroot

[Yann E. MORIN]

Benoit, All,

On Tuesday 24 May 2011 13:20:46 Benoît THÉBAUDEAU wrote:
> # HG changeset patch
> # User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> # Date 1306235541 -7200
> # Node ID 6f6493d05f127328c6168f0a381dbc1080f070c2
> # Parent  420687b63c9775201e84e40f76b4c176996e3bda
> cross-gdb: fix runtime sysroot
> 
> This patch sets the runtime sysroot to fix the following GDB warning:
> "Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code."
> 
> The sysroot can later be changed within gdb with the `set sysroot`
> command if necessary.
> 
> Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> 
> diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
> --- a/scripts/build/debug/300-gdb.sh
> +++ b/scripts/build/debug/300-gdb.sh
> @@ -161,6 +161,7 @@
>              --target=${CT_TARGET}                       \
>              --prefix="${CT_PREFIX_DIR}"                 \
>              --with-build-sysroot="${CT_SYSROOT_DIR}"    \
> +            --with-sysroot="${CT_SYSROOT_DIR}"          \

How does the cross-gdb behaves if the toolchain is relocated? Is gdb able
to detect that, and adapt the sysroot accordingly, like gcc and ld do, or
is it simply hard-coded?

In case relocation does not work, then this would imply that the behavior
of the toolchain (as a whole) is different before and after relocation, in
the former case, sysroot is automatically detected, and in the latter case
the user would have to enter the sysroot location manually with 'set sysroot'.

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

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Benoît THÉBAUDEAU]

Yann, all,

> I am not too fond of this patch for two reasons:
>
> 1) libexpat should be provided by the host:
>    - in case of cross-compilation, it should be installed on your
>    distro.
>      If you want a static gdb, then also install the -dev package
>      from your
>      distro;
>    - in case of canadian-cross, your upper-layer build-system should
>    install
>      libexpat itself.
>
>   Note that the companion libraries are a bit special, as, until
>   recently,
>   distros were not shipping them, or were shipping out-dated
>   versions. This
>   is not the case for libexpat.

I think that keeping the current behavior is an issue. BuildRoot and
many other build environments download and build locally host packages
other packages depend on. In this way, there are no dependencies on
the packages installed on the build system, both for build and runtime.

In CT-NG, building GDB with or without libexpat will succeed, without
the user even knowing that could make a difference. It also means that
a build of a toolchain performed with CT-NG is not reliably reproducible
only from the .config file.

> 2) code duplication to build libexpat
>    - at least, provide a function that build libexpat, and takes as
>      arguments: prefix, build and host
>    - better yet, include it in the companion libraries
>    infrastructure,
>      even if there is no option and no version selection.

That could be done if you changed your mind on 1).

Regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 2 of 2] cross-gdb: fix runtime sysroot

[Benoît THÉBAUDEAU]

Yann, all,

> How does the cross-gdb behaves if the toolchain is relocated? Is gdb
> able
> to detect that, and adapt the sysroot accordingly, like gcc and ld
> do, or
> is it simply hard-coded?

See below.

> In case relocation does not work, then this would imply that the
> behavior
> of the toolchain (as a whole) is different before and after
> relocation, in
> the former case, sysroot is automatically detected, and in the latter
> case
> the user would have to enter the sysroot location manually with 'set
> sysroot'.

Cross-gdb seems to be looking only for the cross ld-linux.so.3.

By default, if --with-sysroot is not provided, gdb searches under /lib,
/usr/lib, etc. and of course does not find what it is looking for. In
that case, `set sysroot` can be issued to solve the issue.

If --with-sysroot is provided, gdb searches under sysroot/lib,
sysroot/usr/lib, etc., and it adapts sysroot automagically if it is
relocated. `set sysroot` can still be used to force the sysroot to some
other place if needed for some reason.

Regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Yann E. MORIN]

Benoit, All,

On Wednesday 25 May 2011 20:00:46 Benoît THÉBAUDEAU wrote:
> Yann, all,
> > I am not too fond of this patch for two reasons:
> > 1) libexpat should be provided by the host:
[--SNIP-]
> I think that keeping the current behavior is an issue. BuildRoot and
> many other build environments download and build locally host packages
> other packages depend on. In this way, there are no dependencies on
> the packages installed on the build system, both for build and runtime.

Granted. They do that stuff. The question is: how far do we want to go?
I'm mostly alone in maintaining and evolving crostool-NG, and I see the
burden falling onto me to support a new companion library yet again; and
then a new companion tool, and then a new [whatever], that could also be
installed using the distro's packages.

Plus, the maintenance work done by the distros far outweights what I
could possibly do to fix/update/... this companion stuff...

> In this way, there are no dependencies on
> the packages installed on the build system, both for build and runtime.

You already have tons of dependencies: a native toolchain, libncurses,
bash, proper sed and grep, make, awk, bison, flex, and so on...
One more won't kill us.

The issue is that there is currently no way to deactivate features in the
menuconfig, based on stuff found by ./configure; so we have to check it
at (ct-ng's) runtime.

> In CT-NG, building GDB with or without libexpat will succeed, without
> the user even knowing that could make a difference.

*This* is the real issue: the user not knowing something went bad, and
discovering only at runtime. The solution to this issue is not to build
libexpat, but to fail early, before even gdb gets compiled.

I believe the real fix would be to fix that.

> It also means that 
> a build of a toolchain performed with CT-NG is not reliably reproducible
> only from the .config file.

Right. I agree that having crosstool-NG's [version,.config] should be enough
to reproduce the toolchain.

> > 2) code duplication to build libexpat
> >    - at least, provide a function that build libexpat, and takes as
> >      arguments: prefix, build and host
> >    - better yet, include it in the companion libraries
> >    infrastructure,
> >      even if there is no option and no version selection.
> 
> That could be done if you changed your mind on 1).

I said I was "not too fond of this patch". I did not say I will not
take it. If you can give good arguments in favor if the change, then
I can change my mind. I did not say 'no'. ;-)

So far, you did not manage to convince me. The only reason that you could
really push for the inclusion is related to canadian-cross. I do believe
that the upper layer build-system should be responsoble for installing
libexpat, but this is not written in stone. I am really pondering to include
it just for this reason. But yet, I am not really happy to do so either...

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

Re: [PATCH 2 of 2] cross-gdb: fix runtime sysroot

[Yann E. MORIN]

Benoit, All,

On Wednesday 25 May 2011 20:21:48 Benoît THÉBAUDEAU wrote:
> > How does the cross-gdb behaves if the toolchain is relocated? Is gdb
> > able
> > to detect that, and adapt the sysroot accordingly, like gcc and ld
> > do, or
> > is it simply hard-coded?
[-SNIP--]
> If --with-sysroot is provided, gdb searches under sysroot/lib,
> sysroot/usr/lib, etc., and it adapts sysroot automagically if it is
> relocated. `set sysroot` can still be used to force the sysroot to some
> other place if needed for some reason.

Applied as #7690196856ce. Thank you!

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

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Bryan Hundven]

2011/5/25 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Benoit, All,
>
> On Wednesday 25 May 2011 20:00:46 Benoît THÉBAUDEAU wrote:
>> Yann, all,
>> > I am not too fond of this patch for two reasons:
>> > 1) libexpat should be provided by the host:
> [--SNIP-]
>> I think that keeping the current behavior is an issue. BuildRoot and
>> many other build environments download and build locally host packages
>> other packages depend on. In this way, there are no dependencies on
>> the packages installed on the build system, both for build and runtime.
>
> Granted. They do that stuff. The question is: how far do we want to go?
> I'm mostly alone in maintaining and evolving crostool-NG, and I see the
> burden falling onto me to support a new companion library yet again; and
> then a new companion tool, and then a new [whatever], that could also be
> installed using the distro's packages.
>
> Plus, the maintenance work done by the distros far outweights what I
> could possibly do to fix/update/... this companion stuff...

I agree with Yann. If we want this, maybe just add another
'has_or_abort', or I suggest having a 'has_or_warn' and setting a
CONFIG_ variable saying that you have libexpat or not, so gdb does the
right thing.
Maintaining companion libraries is a pita.

>> In this way, there are no dependencies on
>> the packages installed on the build system, both for build and runtime.
>
> You already have tons of dependencies: a native toolchain, libncurses,
> bash, proper sed and grep, make, awk, bison, flex, and so on...
> One more won't kill us.
>
> The issue is that there is currently no way to deactivate features in the
> menuconfig, based on stuff found by ./configure; so we have to check it
> at (ct-ng's) runtime.
>
>> In CT-NG, building GDB with or without libexpat will succeed, without
>> the user even knowing that could make a difference.
>
> *This* is the real issue: the user not knowing something went bad, and
> discovering only at runtime. The solution to this issue is not to build
> libexpat, but to fail early, before even gdb gets compiled.
>
> I believe the real fix would be to fix that.
>
>> It also means that
>> a build of a toolchain performed with CT-NG is not reliably reproducible
>> only from the .config file.
>
> Right. I agree that having crosstool-NG's [version,.config] should be enough
> to reproduce the toolchain.
>
>> > 2) code duplication to build libexpat
>> >    - at least, provide a function that build libexpat, and takes as
>> >      arguments: prefix, build and host
>> >    - better yet, include it in the companion libraries
>> >    infrastructure,
>> >      even if there is no option and no version selection.
>>
>> That could be done if you changed your mind on 1).
>
> I said I was "not too fond of this patch". I did not say I will not
> take it. If you can give good arguments in favor if the change, then
> I can change my mind. I did not say 'no'. ;-)
>
> So far, you did not manage to convince me. The only reason that you could
> really push for the inclusion is related to canadian-cross. I do believe
> that the upper layer build-system should be responsoble for installing
> libexpat, but this is not written in stone. I am really pondering to include
> it just for this reason. But yet, I am not really happy to do so either...
>
> 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

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Benoît THÉBAUDEAU]

Yann, all,

> Granted. They do that stuff. The question is: how far do we want to
> go?
> I'm mostly alone in maintaining and evolving crostool-NG, and I see
> the
> burden falling onto me to support a new companion library yet again;
> and
> then a new companion tool, and then a new [whatever], that could also
> be
> installed using the distro's packages.
>
> Plus, the maintenance work done by the distros far outweights what I
> could possibly do to fix/update/... this companion stuff...

I agree.

> You already have tons of dependencies: a native toolchain,
> libncurses,
> bash, proper sed and grep, make, awk, bison, flex, and so on...
> One more won't kill us.
>
> The issue is that there is currently no way to deactivate features in
> the
> menuconfig, based on stuff found by ./configure; so we have to check
> it
> at (ct-ng's) runtime.

Indeed.

> *This* is the real issue: the user not knowing something went bad,
> and
> discovering only at runtime. The solution to this issue is not to
> build
> libexpat, but to fail early, before even gdb gets compiled.
>
> I believe the real fix would be to fix that.

I agree.

How could we do that?
 - We could create a configure-like function in the scripts that would
test for the presence of libexpat on the build system, and fail if not
found.
 - We could add '--with-expat=yes' to the configure options of cross-gdb.
In that way, the configure of cross-gdb would fail if libexpat is not
present, but that failure could occur very late in the toolchain build.

Should we force an error or leave a warning? If --with-expat is not given
or set to auto, there is already a warning issued by the configure of
cross-gdb if libexpat is not found, but it is deeply hidden in the build
log.

Should libexpat be linked statically or dynamically? A dynamic link would
create a runtime dependency of cross-gdb on libexpat, which may be a
problem when moving a built toolchain from one machine to another.

> Right. I agree that having crosstool-NG's [version,.config] should be
> enough
> to reproduce the toolchain.

OK.

> I said I was "not too fond of this patch". I did not say I will not
> take it. If you can give good arguments in favor if the change, then
> I can change my mind. I did not say 'no'. ;-)
>
> So far, you did not manage to convince me. The only reason that you
> could
> really push for the inclusion is related to canadian-cross. I do
> believe
> that the upper layer build-system should be responsoble for
> installing
> libexpat, but this is not written in stone. I am really pondering to
> include
> it just for this reason. But yet, I am not really happy to do so
> either...

OK. The only issue I'd really like to see fixed here is the invisible
dependency on libexpat.

Regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Benoît THÉBAUDEAU]

Bryan, all,

> > Granted. They do that stuff. The question is: how far do we want to
> > go?
> > I'm mostly alone in maintaining and evolving crostool-NG, and I see
> > the
> > burden falling onto me to support a new companion library yet
> > again; and
> > then a new companion tool, and then a new [whatever], that could
> > also be
> > installed using the distro's packages.
> >
> > Plus, the maintenance work done by the distros far outweights what
> > I
> > could possibly do to fix/update/... this companion stuff...
>
> I agree with Yann.

I agree too on this point.

> If we want this, maybe just add another
> 'has_or_abort', or I suggest having a 'has_or_warn' and setting a
> CONFIG_ variable saying that you have libexpat or not, so gdb does
> the
> right thing.
> Maintaining companion libraries is a pita.

That could be a solution. Yann, what do you think?

Regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Yann E. MORIN]

Benoit, Bryan, All,

On Wednesday 25 May 2011 20:53:52 Benoît THÉBAUDEAU wrote:
> > *This* is the real issue: the user not knowing something went bad,
> > and
> > discovering only at runtime. The solution to this issue is not to
> > build
> > libexpat, but to fail early, before even gdb gets compiled.
> >
> > I believe the real fix would be to fix that.
> 
> I agree.
> 
> How could we do that?
>  - We could create a configure-like function in the scripts that would
> test for the presence of libexpat on the build system, and fail if not
> found.
>  - We could add '--with-expat=yes' to the configure options of cross-gdb.
> In that way, the configure of cross-gdb would fail if libexpat is not
> present, but that failure could occur very late in the toolchain build.
> 
> Should we force an error or leave a warning?

The cross-gdb is pretty useless without it, so this has to be an error.

> If --with-expat is not given 
> or set to auto, there is already a warning issued by the configure of
> cross-gdb if libexpat is not found, but it is deeply hidden in the build
> log.
> 
> Should libexpat be linked statically or dynamically?

If the user asked for a static build, then do a full static build.
p;s/static/shared/

> A dynamic link would 
> create a runtime dependency of cross-gdb on libexpat, which may be a
> problem when moving a built toolchain from one machine to another.
[--SNIP--]
> OK. The only issue I'd really like to see fixed here is the invisible
> dependency on libexpat.

OK, we have a few options here:

1) Do the check just when it is needed, in do_debug_gdb_build().
   This is the easiest, very lightweight, but inconvenient for the user
   as the build would have to be restarted.

2) Add a *_prepare function to the API, that gets call at the very beginning
   of the build, and does the necessary checks. Eg.:
     do_debug_gdb_prepare() {
       if [ ! "${libexpat_available}" ]; then
          Aaargh
       fi
     }
  Do it everywhere.
  Also, have ./configure do the has_or_warn (as per Bryan's suggestion).
  This is pretty nice, and lightweight. Rather easy to implement, I think.

3) Provide a way to set defaults to options from ./configure
   - check shared & static libexpat at ./configure time
   - create a .in fragment at ./configure time, eg.:
       config CONFIG_LIBEXPAT_SHARED
           default y
       # CONFIG_LIBEXPAT_STATIC not set: not found
   - add the same option definitons in the top-level config.in,
     and include the .in framgent to set values
   - where applicable, depend on these options to show/hide some options,
     such as static gdb
  This is probably the most complete solution, but it is heavy-weight, maybe
  un-maintanable long-term, error-prone as it needs sync btw config.in and
  ./configure, not easy to see where the defaults come from.

I'd rather go for 2).

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

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Bryan Hundven]

2011/5/25 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Benoit, Bryan, All,
>
> On Wednesday 25 May 2011 20:53:52 Benoît THÉBAUDEAU wrote:
>> > *This* is the real issue: the user not knowing something went bad,
>> > and
>> > discovering only at runtime. The solution to this issue is not to
>> > build
>> > libexpat, but to fail early, before even gdb gets compiled.
>> >
>> > I believe the real fix would be to fix that.
>>
>> I agree.
>>
>> How could we do that?
>>  - We could create a configure-like function in the scripts that would
>> test for the presence of libexpat on the build system, and fail if not
>> found.
>>  - We could add '--with-expat=yes' to the configure options of cross-gdb.
>> In that way, the configure of cross-gdb would fail if libexpat is not
>> present, but that failure could occur very late in the toolchain build.
>>
>> Should we force an error or leave a warning?
>
> The cross-gdb is pretty useless without it, so this has to be an error.
>
>> If --with-expat is not given
>> or set to auto, there is already a warning issued by the configure of
>> cross-gdb if libexpat is not found, but it is deeply hidden in the build
>> log.
>>
>> Should libexpat be linked statically or dynamically?
>
> If the user asked for a static build, then do a full static build.
> p;s/static/shared/
>
>> A dynamic link would
>> create a runtime dependency of cross-gdb on libexpat, which may be a
>> problem when moving a built toolchain from one machine to another.
> [--SNIP--]
>> OK. The only issue I'd really like to see fixed here is the invisible
>> dependency on libexpat.
>
> OK, we have a few options here:
>
> 1) Do the check just when it is needed, in do_debug_gdb_build().
>   This is the easiest, very lightweight, but inconvenient for the user
>   as the build would have to be restarted.
>
> 2) Add a *_prepare function to the API, that gets call at the very beginning
>   of the build, and does the necessary checks. Eg.:
>     do_debug_gdb_prepare() {
>       if [ ! "${libexpat_available}" ]; then
>          Aaargh
>       fi
>     }
>  Do it everywhere.
>  Also, have ./configure do the has_or_warn (as per Bryan's suggestion).
>  This is pretty nice, and lightweight. Rather easy to implement, I think.
>
> 3) Provide a way to set defaults to options from ./configure
>   - check shared & static libexpat at ./configure time
>   - create a .in fragment at ./configure time, eg.:
>       config CONFIG_LIBEXPAT_SHARED
>           default y
>       # CONFIG_LIBEXPAT_STATIC not set: not found
>   - add the same option definitons in the top-level config.in,
>     and include the .in framgent to set values
>   - where applicable, depend on these options to show/hide some options,
>     such as static gdb
>  This is probably the most complete solution, but it is heavy-weight, maybe
>  un-maintanable long-term, error-prone as it needs sync btw config.in and
>  ./configure, not easy to see where the defaults come from.
>
> I'd rather go for 2).

Yann,

I have other uses for 'has_or_warn' and setting
$some-external-lib_available as well.
For instance the problem that ANDY had with fedora packaging only
shared with -devel packages, and needing to install a seperate -static
package in the distribution would allow being able to toggle the
availability of building a static toolchain (i.e. if libncurses5.a is
not availble, don't allow static toolchains, but also warn during
./configure time.)

So I would opt for this solution.

I can provide the 'has_or_warn' code and an example with libncurses5.a
if you want, but you or Benoît should be able to implement
'has_or_warn' as well ;)
IOW... Eventually, I will need this functionality.

> 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

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Yann E. MORIN]

Bryan, Benoit, All,

On Wednesday 25 May 2011 22:25:58 Bryan Hundven wrote:
> I have other uses for 'has_or_warn' and setting
> $some-external-lib_available as well.
> For instance the problem that ANDY had with fedora packaging only
> shared with -devel packages, and needing to install a seperate -static
> package in the distribution would allow being able to toggle the
> availability of building a static toolchain (i.e. if libncurses5.a is
> not availble, don't allow static toolchains, but also warn during
> ./configure time.)

The first step is to warn at ./configure time. Propagating the result
down to kconfig can come later.

We have to be very carefull as to how we do it. We do not want to create
a complex infrastructure for passing such options. Also, we do not want
to add too many such options, or it would become a nightmare to maintain.

Really, I would stay on the safe side and require a bit of knowledge from
the end user to properly setup his/her host.

After all, one should not consider building a toolchain a trivial task;
it really requires some thought before-hand. That we ease the toolchain
build in itself is good; that we abstract all the requirements is bad.

We should only provide safeguards to detect errors, such as this libexpat
stuff, and not forbid doing stupid things, such as asking for a staticaly
linked toolchain when static libs are not installed.

> I can provide the 'has_or_warn' code and an example with libncurses5.a
> if you want, but you or Benoît should be able to implement
> 'has_or_warn' as well ;)

It's not as if has_or_warn was very complex to come up with! ;-)
I'll push a version a bit later.

Then you can build upon this to add your stuff.

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

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Bryan Hundven]

2011/5/26 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Bryan, Benoit, All,
>
> On Wednesday 25 May 2011 22:25:58 Bryan Hundven wrote:
>> I have other uses for 'has_or_warn' and setting
>> $some-external-lib_available as well.
>> For instance the problem that ANDY had with fedora packaging only
>> shared with -devel packages, and needing to install a seperate -static
>> package in the distribution would allow being able to toggle the
>> availability of building a static toolchain (i.e. if libncurses5.a is
>> not availble, don't allow static toolchains, but also warn during
>> ./configure time.)
>
> The first step is to warn at ./configure time. Propagating the result
> down to kconfig can come later.
>
> We have to be very carefull as to how we do it. We do not want to create
> a complex infrastructure for passing such options. Also, we do not want
> to add too many such options, or it would become a nightmare to maintain.
>
> Really, I would stay on the safe side and require a bit of knowledge from
> the end user to properly setup his/her host.
>
> After all, one should not consider building a toolchain a trivial task;
> it really requires some thought before-hand. That we ease the toolchain
> build in itself is good; that we abstract all the requirements is bad.
>
> We should only provide safeguards to detect errors, such as this libexpat
> stuff, and not forbid doing stupid things, such as asking for a staticaly
> linked toolchain when static libs are not installed.

Yup!

What I am thinking to do with this, specifically, is check for
libstdc++.a on the build host to resolve issue #3 at the bottom of:
http://sourceware.org/ml/crossgcc/2011-01/msg00100.html

On Debian, all you need is already provided by `libstdc++6-4.x-dev',
which is required by `g++-4.x (x being 4.4, 4.5, or 4.6).

On Fedora, you can install g++ and still not get the static libraries,
unless you specifically install `libstdc++-static'.

The goal was not to create a warning specific to Fedora, but to say:

*** Warning: ${lib} is missing from your build host. ***\n
*** Because of this some options will not be available. ***

But just depending on the CONFIG_has_${lib} might be good enough.

>> I can provide the 'has_or_warn' code and an example with libncurses5.a

I really did say libncurses5.a. I meant libstdc++.a. Sorry for the confusion. ;)

>> if you want, but you or Benoît should be able to implement
>> 'has_or_warn' as well ;)
>
> It's not as if has_or_warn was very complex to come up with! ;-)
> I'll push a version a bit later.
>
> Then you can build upon this to add your stuff.

Heh, I wasn't sweating the has_or_warn function, it was propagating
the options to kconfig that had me worried.

Well done!

> 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.  |
> '------------------------------^-------^------------------^--------------------'
>

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Benoît THÉBAUDEAU]

Hi Yann, all!

> 2) Add a *_prepare function to the API, that gets call at the very
> beginning
>    of the build, and does the necessary checks. Eg.:
>      do_debug_gdb_prepare() {
>        if [ ! "${libexpat_available}" ]; then
>           Aaargh
>        fi
>      }
>   Do it everywhere.
>   Also, have ./configure do the has_or_warn (as per Bryan's
>   suggestion).
>   This is pretty nice, and lightweight. Rather easy to implement, I
>   think.

The has_or_warn part() of my new patch is ready. Do you prefer the
do_debug_gdb_prepare() that you proposed above, or rather something
like the following?

---
comment "Cross-gdb - disabled (requires expat)"
    depends on !CONFIGURE_has_expat

cconfig GDB_CROSS
    bool
    prompt "Cross-gdb"
    default y
    depends on CONFIGURE_has_expat
    select GDB_GDBSERVER if ! BARE_METAL
    help
      Build and install a cross-gdb for the target, to run on host.
---

I don't see the point of allowing the user to choose a configuration
that will fail as soon as the build starts.

Best regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH 1 of 2] cross-gdb: add XML support

[Yann E. MORIN]

Benoit, Bryan, All,

On Friday 03 June 2011 23:45:53 Benoît THÉBAUDEAU wrote:
> > 2) Add a *_prepare function to the API, that gets call at the very
> > beginning
> >    of the build, and does the necessary checks. Eg.:
> >      do_debug_gdb_prepare() {
> >        if [ ! "${libexpat_available}" ]; then
> >           Aaargh
> >        fi
> >      }
> >   Do it everywhere.

No, the above is crap ( I can say, I wrote it! :-) ). Since I wrote that,
we now have ./configure that can pass options down to kconfig. Let's
use that.

> >   Also, have ./configure do the has_or_warn (as per Bryan's
> >   suggestion).
> >   This is pretty nice, and lightweight. Rather easy to implement, I
> >   think.
> 
> The has_or_warn part() of my new patch is ready. Do you prefer the
> do_debug_gdb_prepare() that you proposed above, or rather something
> like the following?
> 
> ---
> comment "Cross-gdb - disabled (requires expat)"
>     depends on !CONFIGURE_has_expat

Although a comment is a very nice thing to have, I am wondering if it
won't come poluting the code. When I first read it, I was all:
  Oh, a comment. Very nice! 

And then, thinking again, I'm all:
  Wait... Will we have to add such a comment for all features
  conditional on ./configure ? Can we do it in a generic way ?

And then, how do we tell the user to re-run ./configure again so that
the feat is available? Comments can not have help entries (I just
tested). Seems I'll be hanging on the linux-kbuild list a litle
while longer! ;-)

Let's keep the comment for now. If the ./configure warning is explicit
enough, we can live with that.

> cconfig GDB_CROSS
>     bool
>     prompt "Cross-gdb"
>     default y
>     depends on CONFIGURE_has_expat
>     select GDB_GDBSERVER if ! BARE_METAL
>     help
>       Build and install a cross-gdb for the target, to run on host.
> ---
> 
> I don't see the point of allowing the user to choose a configuration
> that will fail as soon as the build starts.

Yes, please go ahead as above, comment included.

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

[PATCH] debug/cross-gdb: check host dependencies

[Benoît THÉBAUDEAU]

# HG changeset patch
# User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
# Date 1307370928 -7200
# Node ID ca6222a138d007bcc7403276c924db0259a0f178
# Parent  2ab553e37517082017b10e992f5b0f5390fc053c
debug/cross-gdb: check host dependencies

Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.

Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"

Hence, expat should be considered mandatory.

On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.

This patch does the following:
 - At configure time, warn the user if either expat or python is missing.
 - In menuconfig, disable the static build options regarding cross-gdb if no
   static version of expat is available, and disable cross-gdb if expat is
   missing.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

diff --git a/config/debug/gdb.in.cross b/config/debug/gdb.in.cross
--- a/config/debug/gdb.in.cross
+++ b/config/debug/gdb.in.cross
@@ -3,10 +3,14 @@
 config STATIC_TOOLCHAIN
     select GDB_CROSS_STATIC if GDB_CROSS
 
+comment "Cross-gdb - disabled (requires expat; re-run ./configure to enable)"
+    depends on !CONFIGURE_has_expat_header || !CONFIGURE_has_expat_library
+
 config GDB_CROSS
     bool
     prompt "Cross-gdb"
     default y
+    depends on CONFIGURE_has_expat_header && CONFIGURE_has_expat_library
     select GDB_GDBSERVER if ! BARE_METAL
     help
       Build and install a cross-gdb for the target, to run on host.
@@ -16,6 +20,7 @@
 config GDB_CROSS_STATIC
     bool
     prompt "Build a static cross gdb"
+    depends on CONFIGURE_has_static_expat
     help
       A static cross gdb can be usefull if you debug on a machine that is
       not the one that is used to compile the toolchain.
diff --git a/config/toolchain.in b/config/toolchain.in
--- a/config/toolchain.in
+++ b/config/toolchain.in
@@ -52,6 +52,7 @@
     bool
     default y
     depends on CONFIGURE_has_static_libstdcxx
+    depends on !GDB_CROSS || CONFIGURE_has_static_expat
     # Add new deps here! :-)
 
 config STATIC_TOOLCHAIN
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -444,6 +444,42 @@
              err="static 'libstdc++' is needed to statically link the toolchain's executables" \
              kconfig=has_static_libstdcxx
 
+has_or_warn  inc="expat.h" \
+             err="The 'expat' header file is needed to build cross-gdb" \
+             kconfig=has_expat_header
+
+expat_libs="$( for x in so dylib a; do \
+                   printf "libexpat.$x "; \
+               done \
+             )"
+has_or_warn  lib="${expat_libs}" \
+             err="The 'expat' library is needed to link cross-gdb's executables" \
+             kconfig=has_expat_library
+
+# Yes, we may be checking twice for libexpat.a
+# The first is because we need one instance of libexpat (shared or static)
+# because it is needed for cross-gdb; the second is because the static version
+# is required for static-linking, and if missing, the option is removed.
+has_or_warn  lib="libexpat.a" \
+             err="static 'expat' is needed to statically link cross-gdb's executables" \
+             kconfig=has_static_expat
+
+python_incs="$( for v in 7 6 5 4; do \
+                    printf "python2.$v/Python.h "; \
+                done \
+              )"
+has_or_warn  inc="${python_incs}" \
+             err="The 'python' header file is needed for some features of cross-gdb"
+
+python_libs="$( for v in 7 6 5 4; do \
+                    for x in so dylib a; do \
+                        printf "libpython2.$v.$x "; \
+                    done; \
+                done \
+              )"
+has_or_warn  lib="${python_libs}" \
+             err="The 'python' library is needed for some features of cross-gdb"
+
 #---------------------------------------------------------------------
 # Compute the version string
 
diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
--- a/scripts/build/debug/300-gdb.sh
+++ b/scripts/build/debug/300-gdb.sh
@@ -139,6 +139,7 @@
             --prefix="${CT_PREFIX_DIR}"                 \
             --with-build-sysroot="${CT_SYSROOT_DIR}"    \
             --with-sysroot="${CT_SYSROOT_DIR}"          \
+            --with-expat=yes                            \
             --disable-werror                            \
             "${cross_extra_config[@]}"
 

Re: [PATCH] debug/cross-gdb: check host dependencies

[Yann E. MORIN]

Benoit, All,

See comments inlined below...

On Monday 06 June 2011 16:50:25 Benoît THÉBAUDEAU wrote:
> # HG changeset patch
> # User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> # Date 1307370928 -7200
> # Node ID ca6222a138d007bcc7403276c924db0259a0f178
> # Parent  2ab553e37517082017b10e992f5b0f5390fc053c
> debug/cross-gdb: check host dependencies
> 
> Cross-gdb depends on expat and python. If either is missing, cross-gdb will
> build successfully, but lacking some features.
> 
> Especially, if expat is missing, cross-gdb will be unable to parse the target
> description, which may lead to runtime malfunctions and the following GDB
> warning:
> "Can not parse XML target description; XML support was disabled at compile time"
> 
> Hence, expat should be considered mandatory.
> 
> On the other hand, the features missing without python are not critical, so
> python should not be considered mandatory.
> 
> This patch does the following:
>  - At configure time, warn the user if either expat or python is missing.
>  - In menuconfig, disable the static build options regarding cross-gdb if no
>    static version of expat is available, and disable cross-gdb if expat is
>    missing.
> 
> Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> 
> diff --git a/config/debug/gdb.in.cross b/config/debug/gdb.in.cross
> --- a/config/debug/gdb.in.cross
> +++ b/config/debug/gdb.in.cross
> @@ -3,10 +3,14 @@
>  config STATIC_TOOLCHAIN
>      select GDB_CROSS_STATIC if GDB_CROSS
>  
> +comment "Cross-gdb - disabled (requires expat; re-run ./configure to enable)"
> +    depends on !CONFIGURE_has_expat_header || !CONFIGURE_has_expat_library
> +
>  config GDB_CROSS
>      bool
>      prompt "Cross-gdb"
>      default y
> +    depends on CONFIGURE_has_expat_header && CONFIGURE_has_expat_library

Why do we need to have two options: headers and libs? Can't we live with
a single option that is the 'aggregate' of the two?

Indeed, the ./configure infrastructure currently does not allow checking
both a header *and* a lib atomically; we currently need to call has_or_*
twice, once for the lib, once for the header. Maybe it would make sense
to be able to check both in a single run?

>      select GDB_GDBSERVER if ! BARE_METAL
>      help
>        Build and install a cross-gdb for the target, to run on host.
> @@ -16,6 +20,7 @@
>  config GDB_CROSS_STATIC
>      bool
>      prompt "Build a static cross gdb"
> +    depends on CONFIGURE_has_static_expat
>      help
>        A static cross gdb can be usefull if you debug on a machine that is
>        not the one that is used to compile the toolchain.
> diff --git a/config/toolchain.in b/config/toolchain.in
> --- a/config/toolchain.in
> +++ b/config/toolchain.in
> @@ -52,6 +52,7 @@
>      bool
>      default y
>      depends on CONFIGURE_has_static_libstdcxx
> +    depends on !GDB_CROSS || CONFIGURE_has_static_expat

I would like to avoid as much as possible that early options in the menu
depends on later options. I mean, I want to avoid the user having to go
back and forth in the menuconfig to see if new options appeared or
disapeared.

CT_STATIC_TOOLCHAIN is early is the menu, while CT_GDB_CROSS is much
later. Which means that, given this initial state (static expat missing):
  CT_GDB_CROSS=y

then firing menuconfig, going to disable CT_GDB_CROSS. This means that the
CT_STATIC_TOOLCHIAN option suddenly appears, and the user would have to go
back into an earlier menu to see that a new option is available.

I would suggest that we instead have CT_GDB_CROSS depends on
CT_STATIC_TOOLCHAIN, a bit like:

  config GDB_CROSS
      bool
      depends on ! STATIC_TOOLCHAIN || has_static_expat
      depends on has_expat_lib && has_expat_hdr

This means that, CT_STATIC_TOOLCHAIN will not depend on CT_GDB_CROSS, while
CT_GDB_CROSS will indeed not be selectable is static toolchain is required,
but static expat is missing.

Yes, this is the reverse as what is done for the static libstdc++. But that's
not really the same context. libstdc++ *is* absolutely required to build a
toolchain; static libstdc++ *is* absolutely requried to build a static
toolchain.

OTOH, static libexpat is *not* absolutely required. It just means that a sub,
non-mandatory component is not buildable.

Briefly looking at the code, it seems rather easy. We migh just need to
change:
  case "${prog}:${inc}:${lib}" in
    ...
  esac

with a succession of independent if-then-fi:
  if [ -n "${prog}" ]; then
    ...
  fi
  if [ -n "${inc}" ]; then
    ...
  fi
  if [ -n "${inc}" ]; then
    ...
  fi

This way, we can check at the same time a prog, an inc and a lib. Not sure
it makes sense to check for a prog, except maybe if we want to check a
version at the same time, such as (purely fictitious):
  has_or_abort prog="expat-config" ver="1.2.3" \
               inc="expat.h"                   \
               lib="libexpat.so"               \
               err="'libexpat 1.2.3' is required to foobar the buz"

Dunno...

>      # Add new deps here! :-)
>  
>  config STATIC_TOOLCHAIN
> diff --git a/configure b/configure
> --- a/configure
> +++ b/configure
> @@ -444,6 +444,42 @@
>               err="static 'libstdc++' is needed to statically link the toolchain's executables" \
>               kconfig=has_static_libstdcxx
>  
> +has_or_warn  inc="expat.h" \
> +             err="The 'expat' header file is needed to build cross-gdb" \
> +             kconfig=has_expat_header
> +
> +expat_libs="$( for x in so dylib a; do \
> +                   printf "libexpat.$x "; \
> +               done \
> +             )"
> +has_or_warn  lib="${expat_libs}" \
> +             err="The 'expat' library is needed to link cross-gdb's executables" \
> +             kconfig=has_expat_library
> +
> +# Yes, we may be checking twice for libexpat.a
> +# The first is because we need one instance of libexpat (shared or static)
> +# because it is needed for cross-gdb; the second is because the static version
> +# is required for static-linking, and if missing, the option is removed.
> +has_or_warn  lib="libexpat.a" \
> +             err="static 'expat' is needed to statically link cross-gdb's executables" \
> +             kconfig=has_static_expat
> +
> +python_incs="$( for v in 7 6 5 4; do \
> +                    printf "python2.$v/Python.h "; \
> +                done \
> +              )"
> +has_or_warn  inc="${python_incs}" \
> +             err="The 'python' header file is needed for some features of cross-gdb"
> +
> +python_libs="$( for v in 7 6 5 4; do \
> +                    for x in so dylib a; do \
> +                        printf "libpython2.$v.$x "; \
> +                    done; \
> +                done \
> +              )"
> +has_or_warn  lib="${python_libs}" \
> +             err="The 'python' library is needed for some features of cross-gdb"

Your checking for both the header and the libs (twice, once for expat, and
once for Python) really seems to imply we need a way to check both at the
same time.

> +
>  #---------------------------------------------------------------------
>  # Compute the version string
>  
> diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
> --- a/scripts/build/debug/300-gdb.sh
> +++ b/scripts/build/debug/300-gdb.sh
> @@ -139,6 +139,7 @@
>              --prefix="${CT_PREFIX_DIR}"                 \
>              --with-build-sysroot="${CT_SYSROOT_DIR}"    \
>              --with-sysroot="${CT_SYSROOT_DIR}"          \
> +            --with-expat=yes                            \
>              --disable-werror                            \
>              "${cross_extra_config[@]}"

Don't we have to disable something if Python is missing, or is it automagic?

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

Re: [PATCH] debug/cross-gdb: check host dependencies

[Yann E. MORIN]

Benoit, All,

On Wednesday 08 June 2011 00:36:15 Yann E. MORIN wrote:
[--SNIP--]

Of course, the following hunk ...
> Briefly looking at the code, it seems rather easy. We migh just need to
> change:
[--SNIP--]
> Dunno...
[--SNIP--]

...  was supposed to come _after_ this sentence:

> Your checking for both the header and the libs (twice, once for expat, and
> once for Python) really seems to imply we need a way to check both at the
> same time.

Sorry for the confusion... :-/

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

Re: [PATCH] debug/cross-gdb: check host dependencies

[Benoît THÉBAUDEAU]

Yann, all,

> Your checking for both the header and the libs (twice, once for
> expat, and
> once for Python) really seems to imply we need a way to check both at
> the
> same time.
[--SNIP--]
> Why do we need to have two options: headers and libs? Can't we live
> with
> a single option that is the 'aggregate' of the two?
>
> Indeed, the ./configure infrastructure currently does not allow
> checking
> both a header *and* a lib atomically; we currently need to call
> has_or_*
> twice, once for the lib, once for the header. Maybe it would make
> sense
> to be able to check both in a single run?
[--SNIP--]
> Briefly looking at the code, it seems rather easy. We migh just need
> to
> change:
>   case "${prog}:${inc}:${lib}" in
>     ...
>   esac
>
> with a succession of independent if-then-fi:
>   if [ -n "${prog}" ]; then
>     ...
>   fi
>   if [ -n "${inc}" ]; then
>     ...
>   fi
>   if [ -n "${inc}" ]; then
>     ...
>   fi
>
> This way, we can check at the same time a prog, an inc and a lib. Not
> sure
> it makes sense to check for a prog, except maybe if we want to check
> a
> version at the same time, such as (purely fictitious):
>   has_or_abort prog="expat-config" ver="1.2.3" \
>                inc="expat.h"                   \
>                lib="libexpat.so"               \
>                err="'libexpat 1.2.3' is required to foobar the buz"
>
> Dunno...

That would indeed be a good idea, but it's not that simple because of ${status}
(it can be duplicated as a solution) and especially of ${var}. What does ${var}
apply to when several of prog/inc/lib are passed at once? Should we simply
forbid this usage?

> I would like to avoid as much as possible that early options in the
> menu
> depends on later options. I mean, I want to avoid the user having to
> go
> back and forth in the menuconfig to see if new options appeared or
> disapeared.
>
> CT_STATIC_TOOLCHAIN is early is the menu, while CT_GDB_CROSS is much
> later. Which means that, given this initial state (static expat
> missing):
>   CT_GDB_CROSS=y
>
> then firing menuconfig, going to disable CT_GDB_CROSS. This means
> that the
> CT_STATIC_TOOLCHIAN option suddenly appears, and the user would have
> to go
> back into an earlier menu to see that a new option is available.
>
> I would suggest that we instead have CT_GDB_CROSS depends on
> CT_STATIC_TOOLCHAIN, a bit like:
>
>   config GDB_CROSS
>       bool
>       depends on ! STATIC_TOOLCHAIN || has_static_expat
>       depends on has_expat_lib && has_expat_hdr
>
> This means that, CT_STATIC_TOOLCHAIN will not depend on CT_GDB_CROSS,
> while
> CT_GDB_CROSS will indeed not be selectable is static toolchain is
> required,
> but static expat is missing.
>
> Yes, this is the reverse as what is done for the static libstdc++.
> But that's
> not really the same context. libstdc++ *is* absolutely required to
> build a
> toolchain; static libstdc++ *is* absolutely requried to build a
> static
> toolchain.
>
> OTOH, static libexpat is *not* absolutely required. It just means
> that a sub,
> non-mandatory component is not buildable.

That makes sense. I'll do that. It's only a matter of priorities between
config options.

> > +            --with-expat=yes                            \
>
> Don't we have to disable something if Python is missing, or is it
> automagic?

Both expat and python are autodetected by gdb's configure by default.

'--with-expat=yes' could be removed since the expat issue is already handled
by the config, but I prefer to keep it to insist on the fact that we want to
make expat compulsory as this option makes gdb's configure fail if expat is
not detected.

Best regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq

[PATCH 2 of 2] debug/cross-gdb: check host dependencies

[Benoît THÉBAUDEAU]

# HG changeset patch
# User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
# Date 1307540863 -7200
# Node ID 9ff0761e151e9aa6f2e3e81d2add55f641893edf
# Parent  a5856225d851cae256be03278343c562b8ebdc54
debug/cross-gdb: check host dependencies

Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.

Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"

Hence, expat should be considered mandatory.

On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.

This patch does the following:
 - At configure time, warn the user if either expat or python is missing.
 - In menuconfig, disable the static build options regarding cross-gdb if no
   static version of expat is available, and disable cross-gdb if expat is
   missing.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

diff --git a/config/debug/gdb.in.cross b/config/debug/gdb.in.cross
--- a/config/debug/gdb.in.cross
+++ b/config/debug/gdb.in.cross
@@ -3,10 +3,15 @@
 config STATIC_TOOLCHAIN
     select GDB_CROSS_STATIC if GDB_CROSS
 
+comment "Cross-gdb - disabled (requires expat; re-run ./configure to enable)"
+    depends on !CONFIGURE_has_expat
+
 config GDB_CROSS
     bool
     prompt "Cross-gdb"
     default y
+    depends on CONFIGURE_has_expat
+    depends on !STATIC_TOOLCHAIN || CONFIGURE_has_static_expat
     select GDB_GDBSERVER if ! BARE_METAL
     help
       Build and install a cross-gdb for the target, to run on host.
@@ -16,6 +21,7 @@
 config GDB_CROSS_STATIC
     bool
     prompt "Build a static cross gdb"
+    depends on CONFIGURE_has_static_expat
     help
       A static cross gdb can be usefull if you debug on a machine that is
       not the one that is used to compile the toolchain.
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -462,6 +462,34 @@
              err="static 'libstdc++' is needed to statically link the toolchain's executables" \
              kconfig=has_static_libstdcxx
 
+expat_libs="$( for x in so dylib a; do \
+                   printf "libexpat.$x "; \
+               done \
+             )"
+has_or_warn  inc="expat.h" \
+             lib="${expat_libs}" \
+             err="The 'expat' header file and library are needed to link cross-gdb's executables" \
+             kconfig=has_expat
+
+# Yes, we may be checking twice for libexpat.a
+# The first is because we need one instance of libexpat (shared or static)
+# because it is needed for cross-gdb; the second is because the static version
+# is required for static-linking, and if missing, the option is removed.
+has_or_warn  lib="libexpat.a" \
+             err="static 'expat' is needed to statically link cross-gdb's executables" \
+             kconfig=has_static_expat
+
+for v in 7 6 5 4; do
+    python_incs="${python_incs}$( printf "python2.$v/Python.h " )"
+    python_libs="${python_libs}$( for x in so dylib a; do \
+                                      printf "libpython2.$v.$x "; \
+                                  done \
+                                )"
+done
+has_or_warn  inc="${python_incs}" \
+             lib="${python_libs}" \
+             err="The 'python' header file and library are needed for some features of cross-gdb"
+
 #---------------------------------------------------------------------
 # Compute the version string
 
diff --git a/scripts/build/debug/300-gdb.sh b/scripts/build/debug/300-gdb.sh
--- a/scripts/build/debug/300-gdb.sh
+++ b/scripts/build/debug/300-gdb.sh
@@ -139,6 +139,7 @@
             --prefix="${CT_PREFIX_DIR}"                 \
             --with-build-sysroot="${CT_SYSROOT_DIR}"    \
             --with-sysroot="${CT_SYSROOT_DIR}"          \
+            --with-expat=yes                            \
             --disable-werror                            \
             "${cross_extra_config[@]}"
 

[PATCH 1 of 2] configure: give check_for() the ability to test several item types at once

[Benoît THÉBAUDEAU]

# HG changeset patch
# User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
# Date 1307540823 -7200
# Node ID a5856225d851cae256be03278343c562b8ebdc54
# Parent  2ab553e37517082017b10e992f5b0f5390fc053c
configure: give check_for() the ability to test several item types at once

Currently, check_for() can only test one of prog, inc or lib at once. This patch
removes this limitation.

Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>

diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -127,75 +127,94 @@
             prog=*|inc=*|lib=*|var=*|ver=*|err=*|kconfig=*)
                 eval ${item%%=*}=\"${item#*=}\"
                 ;;
-            *)  do_error "has_or_abort: incorrect parameters: '$@'";;
+            *)  do_error "check_for: incorrect parameters: '$@'";;
         esac
     done
 
+    case "${prog}:${inc}:${lib}" in
+        ?*:?*:|?*::?*|:?*:?*|?*:?*:?*)
+            if [ -n "${var}" ]; then
+                do_error "check_for: the use of var is not compatible with passing several of [prog|inc|lib] at once"
+            fi
+            ;;
+        ::) do_error "check_for: [prog|inc|lib] is mandatory";;
+    esac
+
     if [ -n "${kconfig}" ]; then
         add_to_kconfig_list "${kconfig}"
     fi
 
-    case "${prog}:${inc}:${lib}" in
-        ?*::)
-            for item in ${prog}; do
-                printf "Checking for '${item}'... "
-                if [ -n "${var}" ]; then
-                    eval val="\${${var}}"
-                    if [ -n "${val}" ]; then
-                        printf "${val} (cached)\n"
-                        add_to_var_list "${var}"
-                        return 0
-                    fi
+    if [ -n "${prog}" ]; then
+        for item in ${prog}; do
+            printf "Checking for '${item}'... "
+            if [ -n "${var}" ]; then
+                eval val="\${${var}}"
+                if [ -n "${val}" ]; then
+                    printf "${val} (cached)\n"
+                    add_to_var_list "${var}"
+                    return 0
                 fi
-                where="$( which "${item}" 2>/dev/null )"
-                if [ -z "${where}" ]; then
+            fi
+            where="$( which "${item}" 2>/dev/null )"
+            if [ -z "${where}" ]; then
+                printf "no\n"
+                continue
+            elif [ -n "${ver}" ]; then
+                str=$( LC_ALL=C "${where}" --version 2>&1   \
+                       |grep -E "${ver}"                    \
+                       |head -n 1
+                     )
+                if [ -z "${str}" ]; then
                     printf "no\n"
+                    unset where
                     continue
-                elif [ -n "${ver}" ]; then
-                    str=$( LC_ALL=C "${where}" --version 2>&1   \
-                           |grep -E "${ver}"                    \
-                           |head -n 1
-                         )
-                    if [ -z "${str}" ]; then
-                        printf "no\n"
-                        unset where
-                        continue
-                    fi
                 fi
-                status="${where}"
-                break
-            done
-            ;;
-        :?*:)
-            for item in ${inc}; do
-                printf "Checking for '${item}'... "
-                if printf "#include \"${item}\"" |gcc -x c -c - -o /dev/null >/dev/null 2>&1; then
-                    where="${item}"
-                    status=yes
-                    break;
-                fi
-                printf "no\n"
-            done
-            ;;
-        ::?*)
-            for item in ${lib}; do
-                printf "Checking for '${item}'... "
-                where="$( gcc -print-file-name="${item}" )"
-                if [ "${where}" != "${item}" ]; then
-                    where="$( readlink "${where}" )"
-                    status=yes
-                    break;
-                fi
-                printf "no\n"
-            done
-            ;;
-    esac
-
-    if [ -z "${status}" ]; then
-        return 1
+            fi
+            status="${where}"
+            break
+        done
+        if [ -z "${status}" ]; then
+            return 1
+        fi
+        printf "${status}\n"
+        unset status
     fi
 
-    printf "${status}"
+    if [ -n "${inc}" ]; then
+        for item in ${inc}; do
+            printf "Checking for '${item}'... "
+            if printf "#include \"${item}\"" |gcc -x c -c - -o /dev/null >/dev/null 2>&1; then
+                where="${item}"
+                status=yes
+                break;
+            fi
+            printf "no\n"
+        done
+        if [ -z "${status}" ]; then
+            return 1
+        fi
+        printf "${status}\n"
+        unset status
+    fi
+
+    if [ -n "${lib}" ]; then
+        for item in ${lib}; do
+            printf "Checking for '${item}'... "
+            where="$( gcc -print-file-name="${item}" )"
+            if [ "${where}" != "${item}" ]; then
+                where="$( readlink "${where}" )"
+                status=yes
+                break;
+            fi
+            printf "no\n"
+        done
+        if [ -z "${status}" ]; then
+            return 1
+        fi
+        printf "${status}\n"
+        unset status
+    fi
+
     if [ -n "${var}" ]; then
         eval ${var}='"'"${where}"'"'
         add_to_var_list "${var}"
@@ -203,7 +222,6 @@
     if [ -n "${kconfig}" ]; then
         eval ${kconfig}=y
     fi
-    printf "\n"
 }
 
 # This function checks for a tool, and aborts if not found

[PATCH 0 of 2] debug/cross-gdb: check host dependencies

[Benoît THÉBAUDEAU]

Hi Yann, all!

This is a new version of my patch making cross-gdb host dependencies more
robust. It takes your comments into account:
 - configure's check_for() can now check for prog/inc/lib at the same time.
 - STATIC_TOOLCHAIN now has priority over GDB_CROSS.

Best regards,
Benoît

Re: [PATCH 1 of 2] configure: give check_for() the ability to test several item types at once

[Yann E. MORIN]

Benoit, All,

On Wednesday 08 June 2011 16:07:20 Benoît THÉBAUDEAU wrote:
> # HG changeset patch
> # User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> # Date 1307540823 -7200
> # Node ID a5856225d851cae256be03278343c562b8ebdc54
> # Parent  2ab553e37517082017b10e992f5b0f5390fc053c
> configure: give check_for() the ability to test several item types at once

Pushed as #a5856225d851. Thank you!

Nice catch for the 'var'iable! :-)

I also added a new changeset (#45a4393fa357) that uses this feature to
check for ncurses lib and header in one run! \o/

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

Re: [PATCH 2 of 2] debug/cross-gdb: check host dependencies

[Yann E. MORIN]

Benoit, All,

On Wednesday 08 June 2011 16:07:21 Benoît THÉBAUDEAU wrote:
> # HG changeset patch
> # User "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
> # Date 1307540863 -7200
> # Node ID 9ff0761e151e9aa6f2e3e81d2add55f641893edf
> # Parent  a5856225d851cae256be03278343c562b8ebdc54
> debug/cross-gdb: check host dependencies

Applied as #9e2761e59a75. Thank you!

I just added a comment saying why cross-gdb can't be selected when the
user has shared expat but not static, and select 'static toolchain',
which hides cross-gdb altogether.

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