Richard Sandiford wrote:
> This may no longer be relevant given the rest of the thread, but for the
> record: what you describe is indeed how things used to work before the
> libtool upgrade.
I see. Thanks for explaining; that puts to rest my vain hope that there
was some simple thing we could do to fix this for Blackfin.
> However, with the libtool upgrade, the shl_load test failed for MIPS
> in the same way as it did for Bernd on Blackfin. Rask got around this
> by adding a "-T" option for the simulator board in top-level configure.
> I still object to this approach for the reasons we discussed before
If I'm understanding correctly:
* You, Benjamin, and I think the previous behavior was best.
* Bernd is flexible, as long as it works.
* Rask prefers the new behavior because he thinks it will be more robust.
Rask, we may have to agree to disagree, as it's clear we both understand
the pros and cons. I agree that making things link is more likely to
work, in the sense that it puts a lower burden on run-time library
configure scripts -- but I also think it increases the risk that the
configure scripts get the wrong answer. And, in some cases, there isn't
any way to get a bare-metal toolchain to link; the necessary bits may be
outside Newlib itself and provided only by the end user.
> If Jie has a patch that gets us around the shl_load failure, I'd be glad
> for us to go that route, and go back to not using the -T simulator options,
> if that's possible.
Bernd kindly forwarded Jie's patch. Unfortunately, it checks
$cross_compile, which means that native and cross compilers will
configure differently, so I don't think we can use that directly.
However, I think there's a solution. In particular, on
libstdc++-v3/configure.ac, we do:
AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL
The AC_LIBTOOL_DLOPEN call enables checking for dlopen support in
libtool. The libtool documentation says:
Enable checking for dlopen support. This macro should be used if
the package makes use of the `-dlopen' and `-dlpreopen' flags,
otherwise libtool will assume that the system does not support
dlopening. The macro must be called *before* `AC_PROG_LIBTOOL'.
But, for a bare-metal toolchain, I don't think we need that. So, I'm
guessing that:
if test "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
fi
will fix the problem. (We already have checks for $with_newlib
elsewhere in configure.ac, so I think this is in the same spirit, though
a libstdc++ maintainer would of course be best to review the patch.)
Bernd, Richard, Rask, would one of you be willing to explore that route?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
