Jakub Jelinek writes:
> Both libraries are actually intended to be installed, not just one.
> Does your patch achieve that?
The patch makes sure that the standalone libgcj_bc library is correctly
built, instead of trying to install the dummy libgcj_bc library that
should only be used for testing
On 04/26/2013 12:22 PM, Matthias Klose wrote:
> I do see this now too, however the root of the problem seems to be a linker
> which defaults to --as-needed (which is the case on SuSe afaik).
Is this a non-standard thing? So SuSe has a special --configure option
which does this? We can always pat
Am 16.04.2013 11:55, schrieb Matthias Klose:
> Am 16.04.2013 11:48, schrieb Jakub Jelinek:
>> On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
>>> Jakub Jelinek writes:
>>>
at dynamic link time it is a dummy library with no symbols that just
adds DT_NEEDED of the latest an
Bryce McKinlay writes:
> It certainly _did_ work as intended previously.
Only by chance, when libtool has to relink the library during install.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something
Jakub Jelinek writes:
> Both libraries are actually intended to be installed, not just one.
No, the other library is never installed, but generated on the fly. See
.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"An
On Tue, Apr 16, 2013 at 5:13 PM, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
>> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
>
> I'm pretty sure it never worked as intented.
It certainly _did_ work as intended previously. Though I've not tested
it for a while.
On Tue, Apr 16, 2013 at 06:13:14PM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
>
> I'm pretty sure it never worked as intented.
Both libraries are actually intended to be installed, not just one.
Does yo
Jakub Jelinek writes:
> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
I'm pretty sure it never worked as intented.
Andreas.
* Makefile.am (toolexeclib_LTLIBRARIES) [USE_LIBGCJ_BC]: Use
install/libgcj_bc.la instead of libgcj_bc.la.
(noinst_
Jakub Jelinek writes:
> If that isn't the installed library, then the bug is that it isn't
> installed.
It's always been this way.
install-exec-hook: install-binPROGRAMS install-toolexeclibLTLIBRARIES \
install-libexecsubPROGRAMS
## Support for libgcj_bc: dummy shared library used only
On Tue, Apr 16, 2013 at 12:11:06PM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > $ readelf -Wa libjava/.libs/libgcj_bc.so
>
> That's not the installed library.
If that isn't the installed library, then the bug is that it isn't
installed. Our spec file reshuffles libraries around h
Jakub Jelinek writes:
> $ readelf -Wa libjava/.libs/libgcj_bc.so
That's not the installed library.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Tue, Apr 16, 2013 at 11:57:54AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > Why would that be a problem? libgcj.so the linker sees (i.e. the dummy
> > library) doesn't intentionally have DT_NEEDED libgcj.so.N, programs and
> > shared libraries linked with -findirect-dispatch sh
Jakub Jelinek writes:
> Why would that be a problem? libgcj.so the linker sees (i.e. the dummy
> library) doesn't intentionally have DT_NEEDED libgcj.so.N, programs and
> shared libraries linked with -findirect-dispatch should be adding
> libgcj_bc.so to DT_NEEDED, not libgcj.so.N.
But the dumm
Am 16.04.2013 11:48, schrieb Jakub Jelinek:
> On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
>> Jakub Jelinek writes:
>>
>>> at dynamic link time it is a dummy library with no symbols that just
>>> adds DT_NEEDED of the latest and greatest libgcj.so.N, which provides
>>> all the s
On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > at dynamic link time it is a dummy library with no symbols that just
> > adds DT_NEEDED of the latest and greatest libgcj.so.N, which provides
> > all the symbols.
>
> Which is exactly the problem. --n
Jakub Jelinek writes:
> at dynamic link time it is a dummy library with no symbols that just
> adds DT_NEEDED of the latest and greatest libgcj.so.N, which provides
> all the symbols.
Which is exactly the problem. --no-copy-dt-needed-entries has been the
default for a long time now.
Andreas.
On Tue, Apr 16, 2013 at 11:13:35AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > That doesn't look right, if -findirect-dispatch now newly needs
> > _Jv_MonitorExit (when has that been added?), then the symbol should
> > be added to libgcj_bc.so.
>
> libgcj_bc.so is just a dummy lib
Jakub Jelinek writes:
> That doesn't look right, if -findirect-dispatch now newly needs
> _Jv_MonitorExit (when has that been added?), then the symbol should
> be added to libgcj_bc.so.
libgcj_bc.so is just a dummy library. You need to look at the installed
file, not the one in the build direct
On Tue, Apr 16, 2013 at 9:38 AM, Jakub Jelinek wrote:
> On Tue, Apr 16, 2013 at 10:35:29AM +0200, Andreas Schwab wrote:
>> Linking with -findirect-dispatch fails with this error:
>>
>> x86_64-linux-gcj -o ecjx -findirect-dispatch
>> --main=org.eclipse.jdt.internal.compiler.batch.GCCMain
>> ../..
On Tue, Apr 16, 2013 at 10:35:29AM +0200, Andreas Schwab wrote:
> Linking with -findirect-dispatch fails with this error:
>
> x86_64-linux-gcj -o ecjx -findirect-dispatch
> --main=org.eclipse.jdt.internal.compiler.batch.GCCMain
> ../../../gcc/libjava/../ecj.jar ecjx.o
> /usr/lib64/gcc/x86_64-s
20 matches
Mail list logo
