Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working properly, due to the undefined
reference to __gxx_personality_v0
Andrew Haley a...@redhat.com writes:
Andreas Schwab wrote:
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working
Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Andreas Schwab wrote:
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker
Andrew Haley a...@redhat.com writes:
Sure, but a generic link test shouldn't require a directory to be
configured in any special way.
I don't see where that requirement is special. After all, RAW_CXX is
definitely not a full C++ compiler (for a good reason, of course).
Andreas.
--
Andreas
Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Sure, but a generic link test shouldn't require a directory to be
configured in any special way.
I don't see where that requirement is special. After all, RAW_CXX is
definitely not a full C++ compiler (for a good reason, of
Andrew Haley a...@redhat.com writes:
Does the test even need to be C++?
Probably not, that's just a side effect of being generic and run for
every configured compiler. It's purpose is to test the linker, although
the outcome may be influenced by flags passed implicitly by the
frontend.
Andreas Schwab wrote:
Why is the libjava directory configured with raw_cxx?
Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
The problem with this is that it keeps the libtool test for dynamic
linker characteristics from working properly, due to the undefined
Paolo Bonzini bonz...@gnu.org writes:
If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
error while loading shared
* Andreas Schwab wrote on Fri, Dec 12, 2008 at 06:43:45PM CET:
Paolo Bonzini bonz...@gnu.org writes:
I think it's easiest to define a cache variable somewhere so that the
test is forced to pass.
There is no cache variable associated with this test.
That's an independent bug which needs
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
So I don't see how to avoid a test here, and hard-coding yes for
gentoo and no for most other distros sounds pretty ugly.
And not very accurate either.
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH,
Andreas Schwab wrote:
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
So I don't see how to avoid a test here, and hard-coding yes for
gentoo and no for most other distros sounds pretty ugly.
And not very accurate either.
What is done to solve the same problem in libstdc++?
Andrew.
Andrew Haley a...@redhat.com writes:
What is done to solve the same problem in libstdc++?
It has basically the same problem, but it is even more special anyway
(and doesn't need to link a c++ program).
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH,
Andreas Schwab wrote:
Paolo Bonzini bonz...@gnu.org writes:
If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
error
Paolo Bonzini bonz...@gnu.org writes:
Andreas Schwab wrote:
Paolo Bonzini bonz...@gnu.org writes:
If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
If it bothers you (does it cause a PR?),
It causes a program to fail to run during build.
./gcj-dbtool -n classmap.db || touch classmap.db
/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
error while loading shared libraries: libgcj.so.10: cannot open shared
* Paolo Bonzini wrote on Fri, Dec 12, 2008 at 10:14:15PM CET:
Yes, this is true. But even though the test that sets
shlibpath_overrides_runpath is run for every compiler, only one result
is then used for all link commands, and that happens to be the result of
the C++ test.
That's
16 matches
Mail list logo
