Re: [PATCH 1 of 3] configure: check for libstdc++.{so,dylib,a}

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Bryan, All,

On Tuesday 31 May 2011 16:34:32 Bryan Hundven wrote:
> On Tue, May 31, 2011 at 5:13 AM, Yann E. MORIN
> <yann.morin.1998@anciens.enib.fr> wrote:
> > +stdcxx_libs="$( for x in so dylib a; do \
> > + Â Â Â Â Â Â Â Â Â printf "libstdc++.$x "; \
> > + Â Â Â Â Â Â Â done \
> > + Â Â Â Â Â Â )"
> > +has_or_abort lib="${stdcxx_libs}" \
> > + Â Â Â Â Â Â err="'libstdc++' shared library was not found"
> > +
> 
> I don't get it. Why 'has_or_abort' and 'has_or_warn' for libstdc++.a.
> In my patch series, I did 'has_or_abort' for {so,dylib}, but
> 'has_or_warn' for libstdc++.a as missing .a is only a warning and a
> kconfig option enabled or disabled.

has_or_abort is there to test the availability of the library.

has_or_warn will check the presence of a specific format of the library,
and if it is missing, will disable some features.

has_or_abort will test each entries in sequence, and stop at the first
it finds. So if you get libstdc++.so, has_or_abort will not check for
the .dylib and .a files. But if only the static one is available, that
is sufficient to fulfill the requirement. If we were to test only for
the .so and the .dylib, having only the .a lib installed would be
considered as an error, when it is not: libstdc++ *is* available.

The has_or_warn was moved to the other patch, because it is semantically
a different issue:
 - in this patch we check that we have a required library;
 - in the second patch, we check whether we can enable a feature, based
   on the presence of a specific format of a library.

What is confusing is that they are both about libstdc++ being available in
one format or another, depending on what we want to check.

Let's summarise:

libstdc++            |   available   |
---------------------+---+---+---+---+
.so/.dylib           | N | N | Y | Y |
.a                   | N | Y | N | Y |
=====================+===+===+===+===+
shared toolchain     | N | N | Y | Y |
static toolchain     | N | Y | N | Y |
static linked in gcc | N | Y | N | Y |
---------------------+---+---+---+---+
Type of build        |   possible    |

For now, 'static toolchain' and 'statically linked libstdc++' are equivalent.
But that can/will change in the future when we add the check for the static
libc.a and libm.a and so on...

Note: this also proves that we should add has_shared_libstdcxx as well to
enable shared building. But we could consider the absent shared version to
be rare enough that it does not matter...

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