* 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.
>
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: c
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/libjav
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
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ü
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.
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ürnbe
* 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 fi
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
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
> re
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
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).
Ca
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 L
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 wi
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 libto
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 ch
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 proper
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
> refe
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 whic
19 matches
Mail list logo
