Benjamin Kosnik wrote:
>> I apologize; I didn't realize that. In that case, you're right; the
>> current approach is just busted. It should become an --enable option,
>> or a hard-coded case statement, or an autoconf test that doesn't require
>> linking stuff.
>
> Really? Like --enable-symvers[=
On Fri, Apr 28, 2006 at 11:21:18PM -0400, DJ Delorie wrote:
>
> > What are you building here? A combined tree including newlib? If
> > so, I bet you aren't specifying --with-newlib; that turns off a
> > bunch
>
> The toplevel configure automatically adds that in a combined tree (or
> at least i
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a hard-coded case statement, or an autoconf test that doesn't require
linking stuff.
Really? Like --enable-symvers[=style]?
http://gcc.gnu.org/onlinedoc
> What are you building here? A combined tree including newlib? If
> so, I bet you aren't specifying --with-newlib; that turns off a
> bunch
The toplevel configure automatically adds that in a combined tree (or
at least it should), if newlib is being built.
The two targets I'm currently workin
On Fri, Apr 28, 2006 at 08:36:50PM -0400, DJ Delorie wrote:
>
> > Well, that sounds like an autoconf bug. If it refuses to work when
> > presented with a pile of compiler options, that just sounds bad.
>
> No, I think it's our bug - we do this:
>
> GCC_NO_EXECUTABLES
> GLIBCXX_ENABLE_SYMVERS([y
On Fri, 28 Apr 2006, DJ Delorie wrote:
> > I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
> > when we've failed to link things?
>
> No, it's explicit:
>
> if test "$build" != "$host"; then
> # We are being configured with some form of cross compiler.
> GLIBCXX_IS_NATI
DJ Delorie wrote:
>> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
>> when we've failed to link things?
>
> No, it's explicit:
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a
> I see -- but why did we set GCC_NO_EXECUTABLES? Don't we only do that
> when we've failed to link things?
No, it's explicit:
if test "$build" != "$host"; then
# We are being configured with some form of cross compiler.
GLIBCXX_IS_NATIVE=false
case "$host","$target" in
*-*-darwin*,
DJ Delorie wrote:
>> Well, that sounds like an autoconf bug. If it refuses to work when
>> presented with a pile of compiler options, that just sounds bad.
>
> No, I think it's our bug - we do this:
>
> GCC_NO_EXECUTABLES
> GLIBCXX_ENABLE_SYMVERS([yes])
>
> You can't logically expect that to wo
> Well, that sounds like an autoconf bug. If it refuses to work when
> presented with a pile of compiler options, that just sounds bad.
No, I think it's our bug - we do this:
GCC_NO_EXECUTABLES
GLIBCXX_ENABLE_SYMVERS([yes])
You can't logically expect that to work, no matter how many compiler
o
DJ Delorie wrote:
>> Right, I understand. Assuming that they exist at this point, you
>> could theoretically pass enough options to make it work -- although,
>> as you say, it's hard to know what those options ought to be. If
>> everything is set up right, it's -I options (for libc headers), -L
>
> Right, I understand. Assuming that they exist at this point, you
> could theoretically pass enough options to make it work -- although,
> as you say, it's hard to know what those options ought to be. If
> everything is set up right, it's -I options (for libc headers), -L
> options (for libc an
DJ Delorie wrote:
>> The key problem is that we have two ways
>
> And then he lists *three* ;-)
:-)
>> To accomplish that, we need to avoid autoconf tests for features that
>> require running target programs;
>
> The problem I'm running into is that I can't even *link* a target
> program at tha
> The key problem is that we have two ways
And then he lists *three* ;-)
> * Hard-coded information about the target
I seem to recall a long time ago, talk of a global target capabilities
database. It proved too unwieldy to implement. However, a toplevel
configury snippet (aka config.gcc) mig
DJ Delorie wrote:
> Another one like libssp.
>
> In libstdc++-v3's configure.ac, we see this:
>
> # This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no.
> GLIBCXX_ENABLE_SYMVERS([yes])
>
> The comment lies. If we haven't yet checked the linker features, it
> will check them
Another one like libssp.
In libstdc++-v3's configure.ac, we see this:
# This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no.
GLIBCXX_ENABLE_SYMVERS([yes])
The comment lies. If we haven't yet checked the linker features, it
will check them, and configure will fail in a comb
16 matches
Mail list logo
