* [PATCH] move libiconv linkage from libgcj.spec.in to libgcj_la_LDFLAGS
@ 2011-06-18 5:52 Jack Howarth
2011-06-20 9:42 ` Andrew Haley
0 siblings, 1 reply; 2+ messages in thread
From: Jack Howarth @ 2011-06-18 5:52 UTC (permalink / raw)
To: gcc-patches; +Cc: tromey, ro, java-patches
The attached patch moves the linkage on $(LDLIBICONV) from libgcj.spec.in to a more correct
direct linkage on libgcj which contains the unresolved symbols. This change also solves problems
when a multilib only has libiconv for one of the two architectures (ie building gcc trunk on
x86_64 fink which lacks a i386 libiconv). Bootstrap and libjava regression tested on x86_64 darwin11.
Okay for gcc trunk?
Jack
2011-06-18 Jack Howarth <howarth@bromo.med.uc.edu>
* libjava/libgcj.spec.in: Don't pass @LDLIBICONV@.
* libjava/Makefile.am (libgcj_la_LDFLAGS): Pass @LDLIBICONV@.
* libjava/Makefile.in: Regenerate.
Index: libjava/libgcj.spec.in
===================================================================
--- libjava/libgcj.spec.in (revision 175163)
+++ libjava/libgcj.spec.in (working copy)
@@ -7,6 +7,6 @@
*startfile: @THREADSTARTFILESPEC@ %(startfileorig)
%rename lib liborig
-*lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ @LIBMATHSPEC@ @LDLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig)
+*lib: @LD_START_STATIC_SPEC@ @LIBGCJ_SPEC@ @LD_FINISH_STATIC_SPEC@ @LIBMATHSPEC@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) @LIBSTDCXXSPEC@ %(liborig)
*jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ @BACKTRACESPEC@ @IEEESPEC@ @ATOMICSPEC@ @LIBGCJ_BC_SPEC@ -fkeep-inline-functions
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am (revision 175163)
+++ libjava/Makefile.am (working copy)
@@ -492,7 +492,7 @@ xlib_nat_files = $(xlib_nat_source_files
libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLDFLAGS) $(extra_ldflags) $(THREADLIBS) \
$(LIBLTDL) $(SYS_ZLIBS) $(LIBJAVA_LDFLAGS_NOUNDEF) \
-version-info `grep -v '^\#' $(srcdir)/libtool-version` \
- $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS) $(LIBGCJ_LD_EXPORT_ALL)
+ $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS) $(LIBGCJ_LD_EXPORT_ALL) $(LDLIBICONV)
libgcj_la_LIBADD = \
classpath/native/fdlibm/libfdlibm.la \
java/lang/Object.lo \
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] move libiconv linkage from libgcj.spec.in to libgcj_la_LDFLAGS
2011-06-18 5:52 [PATCH] move libiconv linkage from libgcj.spec.in to libgcj_la_LDFLAGS Jack Howarth
@ 2011-06-20 9:42 ` Andrew Haley
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Haley @ 2011-06-20 9:42 UTC (permalink / raw)
To: java-patches
On 18/06/11 06:51, Jack Howarth wrote:
> The attached patch moves the linkage on $(LDLIBICONV) from libgcj.spec.in to a more correct
> direct linkage on libgcj which contains the unresolved symbols. This change also solves problems
> when a multilib only has libiconv for one of the two architectures (ie building gcc trunk on
> x86_64 fink which lacks a i386 libiconv). Bootstrap and libjava regression tested on x86_64 darwin11.
> Okay for gcc trunk?
> Jack
>
> 2011-06-18 Jack Howarth <howarth@bromo.med.uc.edu>
>
> * libjava/libgcj.spec.in: Don't pass @LDLIBICONV@.
> * libjava/Makefile.am (libgcj_la_LDFLAGS): Pass @LDLIBICONV@.
> * libjava/Makefile.in: Regenerate.
I think so, and this seems obvious, but there must have been some reason
why this was done. It'd be nice to figure out what that was.
Andrew.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-06-20 9:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-18 5:52 [PATCH] move libiconv linkage from libgcj.spec.in to libgcj_la_LDFLAGS Jack Howarth
2011-06-20 9:42 ` Andrew Haley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).