Re: libjava and raw_cxx
* 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 the bug then I'd say... Ralf what do you think? Yes, my intention was to use one cache variable for the test, as opposed to one per compiler, which should fix this to take the result of the first compiler (C if not disabled). Strictly speaking, that is not precise enough: the user could be using different linkers for different compilers. I don't think we need to support such a setup on GNU/Linux, though. Cheers, Ralf
Re: libjava and raw_cxx
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 >>> object file: No such file or directory >>> Anyway you know you do not need to build C++ executables (only Java) in libjava. >>> See above. >> But that's not a C++ program, it's a Java program. > > 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 the bug then I'd say... Ralf what do you think? Paolo
Re: libjava and raw_cxx
Paolo Bonzini writes: > Andreas Schwab wrote: >> Paolo Bonzini 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 libraries: libgcj.so.10: cannot open shared >> object file: No such file or directory >> >>> Anyway you know you do not need to build C++ executables (only Java) >>> in libjava. >> >> See above. > > But that's not a C++ program, it's a Java program. 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. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libjava and raw_cxx
Andreas Schwab wrote: > Paolo Bonzini 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 libraries: libgcj.so.10: cannot open shared > object file: No such file or directory > >> Anyway you know you do not need to build C++ executables (only Java) >> in libjava. > > See above. But that's not a C++ program, it's a Java program. Paolo
Re: libjava and raw_cxx
Andrew Haley 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, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libjava and raw_cxx
Andreas Schwab wrote: > Ralf Wildenhues 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.
Re: libjava and raw_cxx
Ralf Wildenhues 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, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libjava and raw_cxx
* Andreas Schwab wrote on Fri, Dec 12, 2008 at 06:43:45PM CET: > Paolo Bonzini 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 to be fixed in Libtool anyway. Thanks for the report. I will fix it upstream. I haven't understood the original bug yet, in the sense that I don't quite understand the requirements that GCC has for Libtool's macros. Obviously, in this case link tests are not explicitly forbidden, but implicitly. How can Libtool know when they are supposed to work and when not? What can we assume to work? If I see correctly, then this particular test tries to find out whether -rpath sets DT_RUNPATH in addition to DT_RPATH. Unfortunately, some distributions patch binutils to add that, but at the same time made no other change to ld which would make this behavior apparent to the outside world. 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. Thanks, Ralf
Re: libjava and raw_cxx
Paolo Bonzini 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 libraries: libgcj.so.10: cannot open shared object file: No such file or directory > 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. > Anyway you know you do not need to build C++ executables (only Java) > in libjava. See above. Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libjava and raw_cxx
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
> reference to __gxx_personality_v0 which is defined in libstdc++.
If we weren't using libtool, it would be better to eliminate this and
instead special case the linker in libjava's Makefile.
But using libtool, it is basically a catch-22 (you need C++ in
configure, but then C++ goes in the libtool script, and then you cannot
eliminate it from the makefile).
If it bothers you (does it cause a PR?), I think it's easiest to define
a cache variable somewhere so that the test is forced to pass. Anyway
you know you do not need to build C++ executables (only Java) in libjava.
Paolo
Re: libjava and raw_cxx
Andrew Haley 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. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libjava and raw_cxx
Andreas Schwab wrote: > Andrew Haley 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). Can the path to libstdc++ be added to the test? Does the test even need to be C++? Andrew.
Re: libjava and raw_cxx
Andrew Haley 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 Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libjava and raw_cxx
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Andrew Haley 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 properly, due to the undefined
> reference to __gxx_personality_v0 which is defined in libstdc++.
We don't want libstdc++ linked in libgcj.
If the libtool test wants libstdc++, then it's up to the libtool test
to include libstdc++. Nobody else wants it.
>>> It's not libtool that wants it, but gcc, by generating the reference to
>>> __gxx_personality_v0.
>> Well, yes. I don't quite see your point.
>
> It's a generic link test, independent of the language that the compiler
> accepts. It just assumes that the compiler works.
Sure, but a generic link test shouldn't require a directory to be
configured in any special way. That's the core problem here, not
the fact that libgcj is configured with raw_cxx.
Andrew.
Re: libjava and raw_cxx
Andrew Haley writes:
> Andreas Schwab wrote:
>> Andrew Haley 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 properly, due to the undefined
reference to __gxx_personality_v0 which is defined in libstdc++.
>>> We don't want libstdc++ linked in libgcj.
>>>
>>> If the libtool test wants libstdc++, then it's up to the libtool test
>>> to include libstdc++. Nobody else wants it.
>>
>> It's not libtool that wants it, but gcc, by generating the reference to
>> __gxx_personality_v0.
>
> Well, yes. I don't quite see your point.
It's a generic link test, independent of the language that the compiler
accepts. It just assumes that the compiler works.
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: libjava and raw_cxx
Andreas Schwab wrote:
> Andrew Haley 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 properly, due to the undefined
>>> reference to __gxx_personality_v0 which is defined in libstdc++.
>> We don't want libstdc++ linked in libgcj.
>>
>> If the libtool test wants libstdc++, then it's up to the libtool test
>> to include libstdc++. Nobody else wants it.
>
> It's not libtool that wants it, but gcc, by generating the reference to
> __gxx_personality_v0.
Well, yes. I don't quite see your point.
The libtool test is broken, and should be fixed.
Andrew.
Re: libjava and raw_cxx
Andrew Haley 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 properly, due to the undefined
>> reference to __gxx_personality_v0 which is defined in libstdc++.
>
> We don't want libstdc++ linked in libgcj.
>
> If the libtool test wants libstdc++, then it's up to the libtool test
> to include libstdc++. Nobody else wants it.
It's not libtool that wants it, but gcc, by generating the reference to
__gxx_personality_v0.
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: libjava and raw_cxx
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
> reference to __gxx_personality_v0 which is defined in libstdc++.
We don't want libstdc++ linked in libgcj.
If the libtool test wants libstdc++, then it's up to the libtool test
to include libstdc++. Nobody else wants it.
Andrew.
libjava and raw_cxx
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 which is defined in libstdc++.
configure:15385: checking dynamic linker characteristics
configure:15776: /usr/local/gcc/gcc-20081202/Build/./gcc/xgcc -shared-libgcc
-B/usr/local/gcc/gcc-20081202/Build/./gcc -nostdinc++
-L/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libstdc++-v3/src
-L/usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libstdc++-v3/src/.libs
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
/usr/powerpc64-suse-linux/include -isystem
/usr/powerpc64-suse-linux/sys-include -o conftest -O2 -g -D_GNU_SOURCE
-Wl,-rpath -Wl,/foo conftest.cpp >&5
/tmp/ccqVzuDO.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
configure:15782: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "libjava"
| #define PACKAGE_TARNAME "libjava"
| #define PACKAGE_VERSION "version-unused"
| #define PACKAGE_STRING "libjava version-unused"
| #define PACKAGE_BUGREPORT ""
| #ifdef __cplusplus
| extern "C" void exit (int) throw ();
| #endif
| #define PACKAGE "libjava"
| #define VERSION "version-unused"
| #define LTDL_SHLIBPATH_VAR "LD_LIBRARY_PATH"
| #define AWT_TOOLKIT ""
| #define LIBGCJ_PREFIX "/usr"
| #define USE_LTDL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
Andreas.
--
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
